Model Context Protocol (MCP): A Decision Guide for AI Agents

Key facts, with sources

• LangChain's State of Agent Engineering survey of 1,340 practitioners found 57.3 percent of organizations have agents running in production, with another 30.4 percent actively developing them. (LangChain)
• The same LangChain survey found 89 percent of organizations have implemented observability for their agents but only 52 percent do systematic evaluation. (LangChain)
• Deloitte predicts 25 percent of companies using generative AI launched agentic AI pilots in 2025, growing to 50 percent by 2027. (Deloitte Insights)
• By December 2025 the Model Context Protocol had over 97 million monthly SDK downloads and more than 10,000 active MCP servers in production use. (Pento)
• PwC's AI agent survey found 79 percent of companies report AI agents are already being adopted, and 66 percent of adopters say agents deliver measurable value through increased productivity. (PwC)
• In December 2025 Anthropic donated the Model Context Protocol to the Agentic AI Foundation under the Linux Foundation, co-founded with Block and OpenAI, making the agent connector layer vendor-neutral. (Anthropic)

The problem MCP actually solves

Before MCP, every agent framework spoke its own dialect for tools. If you had three models (say Claude, GPT, and an open-weight model) and five internal tools (CRM, database, search, calendar, payments), you were on the hook for up to fifteen bespoke integrations — and every one of them broke differently when a model or an API changed. That is the N×M integration explosion.

MCP collapses it to N+M. Each tool is implemented once as an MCP server. Each agent implements the MCP client once. Any client can then talk to any server. It is the same move the Language Server Protocol made for code editors: instead of every editor integrating every language, each language ships one server and each editor ships one client. MCP does that for AI tools and context.

How MCP works: clients, servers, and transports

An MCP host — Claude Desktop, an IDE, or your own agent app — runs an MCP client. Each capability you want to expose runs as an MCP server, and a server offers three kinds of primitive. Tools are functions the model can call (query a database, send an email). Resources are read-only context the model can pull in (a document, a policy, a schema). Prompts are reusable, parameterized templates a server can hand to the client.

Communication is JSON-RPC 2.0 over one of two transports: stdio, where the server runs as a local subprocess and is ideal for desktop and local tools, and streamable HTTP (with server-sent events), where the server runs remotely behind a URL. The model never sees the transport — it just sees a discoverable, typed list of tools and resources.

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("inventory")

@mcp.tool()
def get_stock(sku: str) -> int:
    """Return the number of units in stock for a SKU."""
    return db.stock_for(sku)  # your real data access

@mcp.resource("policy://returns")
def returns_policy() -> str:
    """The current returns policy the agent is allowed to cite."""
    return load_policy_text()

if __name__ == "__main__":
    mcp.run()  # stdio transport by default; swap to HTTP for remote

When to build on MCP — and when not to

The honest test is reuse. MCP earns its keep when the same tools are used by more than one agent, model, or surface — an internal ops agent, a customer-facing chatbot, and a teammate's Claude Desktop all hitting the same inventory server. It also pays off when you expect to swap or add models, because the tools do not change when the model does.

It is overhead you do not need when a single agent calls a single API on a single path. There, native function calling is simpler — you are not integrating an ecosystem, you are making one call. The rule of thumb: one agent and one tool is YAGNI; a fleet of tools reused across agents is exactly what MCP is for. Building an MCP server so one script can call one endpoint is the AI equivalent of a microservice for a to-do list.

Security: the part teams underestimate

An MCP server exposes real capabilities to a model that can be steered by untrusted input, so treat every server as a genuine API boundary, not a convenience wrapper. The failure modes that showed up across 2025 were predictable: tools scoped far too broadly (a 'run SQL' tool with write access), remote servers with no authentication, prompt injection in retrieved content that reaches a tool, and confused-deputy problems where the agent is tricked into using its own credentials for the attacker.

The mitigations are ordinary engineering discipline. Give each tool the narrowest scope that works — read-only unless it must write. Put real auth (OAuth or signed tokens) on any remote server. Require human approval for irreversible or high-value actions like payments or deletions. Allowlist which servers a host may connect to. And log every tool call with its arguments, because when something goes wrong the trace is the only thing that tells you what the agent actually did.

Cost and effort: what adoption really takes

Wrapping an existing internal API as an MCP server is usually a day or two of work — and almost none of that is the protocol. The SDK handles the JSON-RPC plumbing; the real work is deciding tool scopes, wiring authentication, writing the argument schemas, and testing against a real agent on inputs you did not hand-pick. The ongoing cost is that each server becomes a small product surface you own: versioned, monitored, and secured like any other service.

That is the point where a lot of teams bring in senior help — not to write the happy-path server, which the SDK makes easy, but to get the scoping, auth, and guardrails right before an agent with tool access faces real users. Getting those wrong is how a helpful agent becomes an incident.

When to hire senior help

Bring in senior help when the agent must touch production systems or customer data, because integration, security, and reliability are where inexperienced builds fail rather than model quality. If a pilot is stuck at the demo stage, an experienced engineer adding evals and guardrails is usually faster and cheaper than rebuilding from scratch. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships AI — AI Agent Development projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Shipping agents with logging but no evals, so teams can see traces but never measure task success rates and regressions ship silently
• ✕Giving one agent dozens of tools instead of a focused toolset, which degrades tool-selection accuracy and inflates token costs
• ✕Hand-rolling custom integration glue for every data source instead of using MCP, which is now the vendor-neutral standard backed by Anthropic, OpenAI, and the Linux Foundation
• ✕Validating only on happy-path demo prompts and skipping failure-mode testing, a core reason roughly 88 percent of agent pilots never reach production

Frequently asked questions

Sources

• LangChain
• Deloitte Insights
• Pento
• PwC
• Anthropic