MCP: the protocol that became as common as a web server

Bell System switchboard operators — turning M×N point-to-point wiring into one patch panel. NARA, public domain.

A protocol nobody asked for, that everybody now runs

In November 2024, Anthropic open-sourced a specification called the Model Context Protocol. It landed with the modest energy of an internal tool being released because someone thought it might be useful — a wire format, a handful of SDKs, some reference servers for Google Drive, Slack, GitHub, Postgres, and Puppeteer. The launch did not trend. Most engineers who would later run an MCP server every day did not hear about it that week.

Sixteen months later the SDKs were being pulled down 97 million times a month, up from roughly 2 million at launch. For comparison in that same writeup, the React npm package took about three years to reach 100 million monthly downloads; MCP got to comparable scale in sixteen months. By the time Anthropic donated the protocol to the Linux Foundation's Agentic AI Foundation in December 2025, there were over 10,000 active public MCP servers and the client list had stopped being a list of Anthropic products. Running an MCP server, in 2026, is about as remarkable as running a web server. That is the claim I want to take seriously, because it is both true and frequently misunderstood.

The misunderstanding is in both directions. People who have only seen the marketing think MCP is a kind of intelligence layer, an AI thing. People who have read the spec sometimes think it is a thin wrapper over function calling that got lucky. Neither is right. MCP is a boring, well-scoped integration protocol, and boring well-scoped integration protocols are exactly the kind of thing that quietly takes over an industry.

What it actually is, mechanically

Strip the AI framing off and MCP is a client-server protocol with a wire format you already know. The wire format is JSON-RPC 2.0 — the same request/response envelope that has been around since the 2000s, with method, params, and id fields. There is nothing neural in the protocol itself. A model never appears in the spec. What appears is a host application (Claude Desktop, Cursor, an agent runtime), which spins up one or more clients, each of which maintains a connection to a server that exposes some capability.

The server exposes that capability through exactly three primitives, and the entire conceptual surface of MCP fits in those three nouns:

• Tools — executable actions the model can invoke. create_issue, run_query, send_message. Each tool has a name, a JSON-schema description of its arguments, and a return value. This is the primitive most people mean when they say "MCP."
• Resources — read-only data the host can pull into context. A file, a database row, a documentation page. Addressable, listable, fetchable, but not executed.
• Prompts — reusable templates the server offers to the host, parameterised pieces of instruction a user can invoke deliberately.

Each primitive has standardised list and get/call methods, so a client that has never seen a particular server before can connect, ask "what do you have?", and get a machine-readable inventory back. That discovery step is most of why the thing composes.

Transport is the other piece, and it is deliberately small. The spec defines two transports: stdio, where the host launches the server as a subprocess and they speak JSON-RPC over stdin/stdout, which is what you want for a local tool running on your own machine; and Streamable HTTP, where the server is an independent process handling multiple clients over HTTPS, optionally using server-sent events to stream messages back. Local tools use stdio, remote/shared tools use HTTP. That is the whole transport story.

flowchart LR
    H["Host app<br/>(Cursor, Claude Code,<br/>agent runtime)"]
    C1["MCP client 1"]
    C2["MCP client 2"]
    S1["MCP server:<br/>filesystem<br/>(tools + resources)"]
    S2["MCP server:<br/>Postgres<br/>(tools)"]
    H --> C1 --> S1
    H --> C2 --> S2
    S1 -. "stdio / JSON-RPC" .-> C1
    S2 -. "HTTP+SSE / JSON-RPC" .-> C2

If you have written a language-server-protocol integration, this will feel familiar, and that is not an accident. MCP is openly modelled on LSP, the protocol that let one editor-feature implementation (autocomplete for Go, say) work across every editor that speaks LSP. MCP is doing the same trick one layer up: write the integration once, run it under any host that speaks the protocol.

Why it won: M×N became M+N

The reason MCP spread is not that it is clever. It is that it solves a counting problem that was making everyone miserable.

Before MCP, every AI application that wanted to talk to a tool had to implement that integration itself, against that tool's own idiosyncratic API, in that application's own plugin format. Cursor's GitHub integration and Claude Desktop's GitHub integration and some startup's agent's GitHub integration were three separate pieces of work that did the same thing. With M applications and N tools, the industry was on the hook for something close to M×N custom integrations — Anthropic's own framing was the combinatorial explosion: ten applications times a hundred tools is a thousand bespoke connectors, each maintained separately, each breaking separately.

A shared protocol collapses that to M+N. Implement the client side once per application, implement the server side once per tool, and any client works with any server. Write an MCP server for your company's internal billing system and it works in Cursor, in Claude Code, in Zed, in a custom agent, with no per-host work. This is exactly the economics that made USB win over a drawer full of proprietary connectors, and it is the same economics that, in the post on why every AI IDE is the same model with a different system prompt, turns IDE-specific tool integrations into commodity infrastructure. A custom MCP server written for one editor works in any of the others without modification, which is precisely why the tool layer is no longer where editors compete.

The adoption sequence followed the M+N logic. Anthropic shipped it; the open-source community built servers faster than anyone expected; and then the moment that mattered arrived in March 2025, when OpenAI — a direct competitor — adopted MCP across its products, with Sam Altman saying support was live in the Agents SDK. Google followed with Gemini and Vertex AI, Microsoft with Copilot Studio, AWS with Bedrock. On the client side the editors fell in line — Cursor and GitHub Copilot ship native MCP support, Zed, JetBrains, and Continue all speak it. Once your largest competitor implements the same protocol you do, the protocol has stopped being your protocol. That is the moment a vendor spec becomes a standard, and it is the moment the M+N math becomes inevitable rather than aspirational.

A protocol is not a solution

Here is the part the 97-million-downloads headline papers over. MCP standardises how a tool is described and called. It standardises almost nothing about whether calling that tool is a good idea. The hard parts of connecting a language model to your systems are still, in May 2026, unsolved — and a protocol cannot solve them, because they are not protocol-shaped problems.

Start with authentication and authorization. MCP added an OAuth-based auth story to the spec over 2025, but "the protocol supports auth" and "the ecosystem of 10,000 community servers is configured securely" are very different statements. A locally-launched stdio server runs with your user's privileges and your environment variables, which means a malicious or sloppy server is a malicious or sloppy program running as you. Security researchers spent 2025 cataloguing tool-poisoning and prompt-injection attacks that ride in through MCP servers, and none of those are protocol bugs — they are the predictable consequence of giving a stochastic text generator a standardised, frictionless way to invoke arbitrary actions. Simon Willison's lethal trifecta — untrusted input, private data, and tool use sharing one context window — gets easier to assemble accidentally when every tool is one config line away, not harder. MCP did not create that risk surface. It paved a very smooth road across it.

Then there is tool quality, which is the quiet one. A protocol guarantees that a tool's description is well-formed JSON. It guarantees nothing about whether the description is good — whether the tool name is unambiguous, whether the argument schema is tight enough to prevent the model from passing garbage, whether the returned data is shaped so the model can actually use it. A model deciding which of 200 available tools to call is doing that decision in the same fallible way it does everything else, and as I argued in the post on why AI cannot guardrail against AI, wrapping a bad decision in a well-specified envelope does not make it a good decision. The more tools you expose over MCP, the more you are loading the context window with tool descriptions, and the more you are subject to exactly the context-rot and lost-in-the-middle degradation that gets worse as input grows. A clean protocol can deliver a cluttered, error-prone context with perfect fidelity.

And there is the part that touches every team running these things: MCP makes it trivially easy to give an agent more capability than anyone on the team understands. The protocol is so frictionless that "add the database MCP server" is a one-line config change, and now a model can run queries against production. The comprehension cost of that — who reviewed which tools are exposed, who can explain what the agent is allowed to touch — is exactly the kind of cost that, as in twenty LLMs do not make a team, the dashboards never measure until an incident forces the question.

Where it sits in the protocol stack

MCP's scope is narrow on purpose: it connects one agent to its tools and data. It says nothing about how two agents talk to each other, which is a different problem that spawned a different set of protocols — Google's A2A, IBM's ACP, and the rest of the still-forming agent-protocol landscape. Keeping those distinct matters, because the marketing is actively blurring them, and untangling agent↔tool from agent↔agent is the subject of the sibling post on the MCP/A2A/ACP landscape. The short version: MCP won the agent↔tool layer decisively, and the agent↔agent layer is still a war.

It is also worth being precise about what MCP's success does and does not signal about what "agentic" actually means. Having a tidy protocol for tool calls does not make a system an agent. A single LLM call that happens to invoke one MCP tool is still a single LLM call. MCP is plumbing for the tool-use leg of an agent loop; it is not the loop, the planning, the memory, or the retry logic. Plenty of "agentic" products are a prompt plus one MCP server plus a press release.

A short close

The honest way to describe MCP is that it is the LSP of tool use: an unglamorous integration protocol that won by making the integration count linear instead of quadratic, and that everyone now implements because everyone else does. JSON-RPC, three primitives, two transports, a client-server split. That is the whole thing, and the boringness is the point — boring, well-scoped protocols are the ones that become infrastructure.

What MCP is not, is a fix for any of the genuinely hard problems in putting a language model in front of real systems. Auth, the security blast radius, tool quality, context bloat, and the comprehension debt of handing an agent capabilities nobody audited — all of those are still open, all of those still need deterministic, externally-verifiable answers, and none of those get easier because the function-call envelope is now standardised. We have agreed on how to wire the tools in. We have not agreed on much else, and pretending the protocol is the solution is how the next round of incidents gets written. Running an MCP server is as common as running a web server now. Running one well is exactly as hard as it ever was.