What Is MCP? The Complete Guide to Model Context Protocol

By Jonathan Hildebrandt, Co-Founder at Pondero Last updated: April 27, 2026

Model Context Protocol is not "USB-C for AI." That analogy, which Anthropic itself uses, sells the protocol short and oversells it at the same time. MCP does one specific thing: it moves tool discovery and invocation out of your application code and behind a network boundary the model client controls. That is the whole bet. Everything that is good about MCP and everything that is still broken about it follows from that single design decision. This guide is about the decision, not the marketing.

Here is the claim to take away: adopt MCP when you have more than one AI client or more than a handful of tools and the set is changing. Use a direct function call when you have one app and a fixed, small tool set. The crossover is real and most teams cross it without noticing.

The problem, stated precisely

The standard framing is the "M x N problem": M AI apps times N tools equals M times N bespoke integrations. True, but the cost is not the integration count. It is where the integration code lives.

Without MCP, the connector for GitHub lives inside Cursor's codebase, and a second copy lives inside your custom agent, and a third inside Claude Desktop. Each copy ships on that app's release cycle, carries that app's auth assumptions, and breaks independently when GitHub changes an endpoint. The tool author has no way to fix all three at once because they do not own any of the three.

MCP inverts ownership. The GitHub connector becomes one process the tool author ships and maintains. Every client that speaks MCP discovers it at runtime. The integration code crossed a boundary: out of N application codebases, into one server the right party owns. That is the mechanism. "Standardized protocol" is the surface description; relocated ownership is what actually changes your maintenance math.

What the protocol actually constrains

MCP is JSON-RPC 2.0 over one of two transports, with a capability negotiation handshake on top. Stripped to what matters:

The handshake is the load-bearing part. When a client connects, it sends an initialize request with its protocol version and capabilities; the server replies with its own; the client confirms with an initialized notification. Nothing happens before both sides agree. This is why an MCP server written in 2024 still works with a 2026 client: the version is negotiated, not assumed. It is also why a client that does not implement a capability simply does not see the tools that depend on it, rather than crashing. The handshake is the compatibility contract a vendor page never explains.

Four capability types, and they are not equivalent. Tools are model-controlled (the model decides when to call them). Resources are application-controlled (the host decides when to fetch them, identified by URIs like github://repo/issues/42). Prompts are user-controlled (they appear in the UI as selectable templates). Sampling lets the server ask the client's model for a completion, which inverts the usual direction and requires explicit user approval. Most servers only implement Tools, and most articles only describe Tools, which is why people are surprised when a Resources-heavy server behaves differently. The control axis (model vs app vs user) is the distinction that predicts behavior.

Two transports with a sharp tradeoff. stdio launches the server as a local subprocess and pipes JSON-RPC over stdin/stdout. It is the simplest setup and the default people start with. Streamable HTTP (March 2025 spec; it replaced the earlier HTTP+SSE transport, which was deprecated in mid-2025 because its persistent-connection model misbehaved behind load balancers) is for remote servers. The tradeoff is not "local vs remote." It is statefulness: stdio servers can hold process state for free; Streamable HTTP servers that want to scale horizontally must be effectively stateless because a load balancer can route consecutive requests to different instances. If you build on MCP for production, this is the constraint that will cost you, and it is the one the 2026 roadmap is still actively working on.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/path/to/your/directory"
      ]
    }
  }
}

That config tells an MCP client (the block above is the Claude Desktop format) to launch a filesystem server over stdio. Restart the client, ask it to list files in the directory, and you have confirmed the handshake worked. This is the smallest end-to-end test and the fastest way to learn whether your client implements MCP correctly.

Where MCP earns its keep, with numbers

We rebuilt the Pondero editorial research workflow on MCP in March 2026. The before state: a tool comparison meant 8 to 12 open browser tabs (pricing, changelogs, Reddit, G2), specs hand-copied into Notion, then writing from the Notion doc. Keeping published articles current as vendors changed pricing was a quarterly calendar item we routinely skipped.

The after state is three servers:

• Filesystem server with read access to our content directory. The query "which articles mention Cursor's 40-tool limit and might be stale" now returns a list with context in seconds instead of a grep plus manual scan.
• Brave Search server for live pricing checks during the writing session rather than from a stale manual sweep.
• A custom stdio server wrapping our internal review database (specs, pricing history, affiliate registry, test notes), so "has Cursor changed pricing since we last reviewed it" is a structured query, not a question we ask each other.

Measured effect: research time for a new comparison dropped from roughly 4 hours to roughly 45 minutes, and we now catch pricing changes within about a week because the Brave query runs as part of normal drafting. The custom server took an afternoon to write against the TypeScript SDK. None of this required a framework. That is the candid case for MCP at small scale: a filesystem plus search setup is the highest-return hour you can spend on a content operation.

When NOT to use MCP

This is where most coverage hedges and the recommendation should not.

One app, fixed small tool set: use function calling directly. Function calling defines how a model requests an action; MCP defines how actions are discovered and connected across apps. They are complementary (most MCP clients invoke MCP tools through the model's own function-calling layer). If you are shipping a single product with five tools that only your product needs, MCP adds a process, a handshake, and a transport for zero ownership benefit, because you already own all the code. Adopt MCP the moment a second client needs the same tools, or the tool set starts changing weekly. Before that, it is over-engineering, and the official docs will not tell you this.

You need orchestration, not connection: that is a framework's job. LangChain and LlamaIndex are orchestration layers for multi-step reasoning and RAG pipelines. MCP is a connection layer. They sit at different levels and LangChain already consumes MCP servers, so this is rarely either/or. If your problem is "chain these eight steps with retries and branching," MCP solves none of it.

The API is internal, unusual, or latency-critical: a direct integration can still win. MCP's value scales with reuse. A one-off connection to an internal service with strict latency budgets may not be worth the extra hop.

Approach	Layer	Reusable across apps	Best for
Function calling	Model API	No (per app)	One app, small fixed tool set
LangChain / LlamaIndex	Orchestration	Framework-bound	Multi-step pipelines, RAG
Custom API integration	Application	No	Unusual or latency-critical needs
MCP	Protocol	Yes	Tools shared across clients, changing set

The part the adoption headlines skip: security

Every major client now speaks MCP, and since December 2025 the protocol is governed by the Agentic AI Foundation under the Linux Foundation, with platinum members including AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI. That settles the "will this be abandoned" question. It does not settle the question that actually matters for your deployment, which is that MCP enlarges the attack surface in a way teams underestimate.

The protocol moves tool invocation behind a boundary the model controls, which is exactly the property attackers want. Three concrete failure modes:

• Prompt injection into tool calls. Untrusted content the model reads can steer which MCP tools it invokes and with what arguments. The boundary that makes MCP convenient also makes the model a confused deputy.
• Tool poisoning. A malicious server can write tool descriptions designed to lure the model into unsafe calls. The client trusts the server's self-description by default.
• Over-broad scope. A "GitHub server" typically holds access to every repo, not the one you are working in. Scope at install time, because the default is wide.

Treat installing a community MCP server with the same suspicion as installing an npm dependency, because it is the same trust model. The protocol now specifies OAuth 2.1 with PKCE for remote servers, and the June 2025 spec update closed a token-leakage vector, but enterprise auth (SSO, fine-grained scoping, audit trails) is still being built out and is a stated 2026 priority. For local servers on your own machine, the risk is manageable. For production handling sensitive data, evaluate each server as untrusted code, because that is what it is.

What would change this recommendation

The advice (default to MCP above the multi-client / changing-toolset threshold, direct calls below it) flips under two conditions. If you operate a single tightly-controlled product where the tool set is genuinely fixed, the ownership benefit never materializes and MCP is pure overhead; stay with function calling. And if you are deploying remote servers at scale before the transport-scalability and enterprise-auth roadmap items land, you are buying infrastructure work the protocol has not finished; either self-limit to stdio and local servers, or budget for the gap explicitly.

FAQ

Is MCP only for Claude? No. It is an open protocol governed by the vendor-neutral AAIF and supported by ChatGPT, Gemini, GitHub Copilot, Cursor, VS Code, and dozens of clients. Anthropic created it and open-sourced it in November 2024.

Is it free? The specification is open and free. Building clients or servers costs nothing. Some hosted server platforms charge for infrastructure; the protocol does not.

Do I need to be a developer? Mostly yes today. Setup means editing config files and occasionally troubleshooting transports. Some clients now offer one-click server installs, but it is still developer-oriented.

How is this different from ChatGPT plugins? Plugins were proprietary, platform-locked, approval-gated, and discontinued. MCP is open and cross-platform; anyone ships a server without any vendor's permission.

Can I build my own server? Yes. Official SDKs exist for TypeScript and Python. Define tools with names, descriptions, and parameter schemas, implement the handlers, wire them with the SDK. A focused server is an afternoon of work, as our internal one was.

What to do tomorrow morning

If you run more than one AI client or your tool set changes monthly, install a filesystem and a search server against a real workflow this week and measure the time delta on one recurring task. If you ship a single product with a fixed tool set, skip MCP and revisit when a second consumer appears. Either way, treat every third-party server as untrusted code and scope it narrowly at install. The protocol is now infrastructure. Whether it belongs in your stack today is still a decision with a wrong answer in both directions.

Go deeper: MCP server reviews, setup guides, and the official MCP documentation.