MCP is the protocol the agent era needed

When Anthropic released the Model Context Protocol in November 2024, the response on twitter was muted. There were no demos. There were no benchmarks. There was just a spec, a reference implementation, and a slightly dry blog post. By the standards of the AI discourse in late 2024, this was almost rude.

Six months later it's clear they shipped the most important infrastructure release of the year. MCP is winning. It's winning quietly, the way good infrastructure wins. And the reason it's winning says something useful about what the agent era is actually about.

what MCP is, in one paragraph

MCP is a standard way for an LLM application to discover and use tools that live somewhere outside the model. An MCP server exposes some capabilities (functions, resources, prompts). An MCP client (your agent, your IDE, your assistant) connects to the server, asks what's available, and calls what it needs. The transport is JSON-RPC. The shape of a tool definition is standardized. The auth pattern is bring-your-own. That's most of it.

If this sounds boring, that's the point. The actual thing MCP solves is a protocol-shaped problem, not a framework-shaped one, and Anthropic correctly noticed.

the actual problem it solves

For about two years prior, every AI application built tools the same way: by writing them inline, in the application's codebase, as functions the model could call. Your agent had your tools. My agent had my tools. Every team rebuilt the wrapper around Notion, around Slack, around their internal database. The tool definitions varied slightly. The auth handling varied a lot. The error semantics varied wildly. Nobody could share anything.

This was a coordination problem dressed up as a technical problem. Everyone was doing the same five things (talking to Postgres, talking to a calendar, talking to a vector store, talking to a CRM, talking to a doc store). Everyone was writing the same five wrappers. Everyone was hitting the same five edge cases. And because there was no protocol, none of that work was portable.

MCP makes it portable. You write a Postgres MCP server once. Every agent that speaks MCP can use it. The agent and the server evolve on different release cycles. They don't have to know about each other's internals. They just have to agree on the wire format.

This is the part the framework people kept missing. The bottleneck was never the model. It was the seam between the model and the world. You can't solve a seam with a framework. You solve a seam with a protocol.

why a protocol and not a framework

Frameworks impose. Protocols compose. That's the one-line version.

When you ship a framework (LangChain, AutoGen, the rest), you are saying: here is the way to think about your problem. Use my abstractions. Live in my world. The framework wins if its abstractions are the right ones for your problem. When they're not, you have a hard fight on your hands, because the framework's internals assume the framework's worldview.

A protocol says nothing about how either side organizes itself. The MCP server can be a python script, a rust binary, a kubernetes deployment, a chrome extension, a serverless function. The MCP client can be Claude Desktop, an internal agent, an IDE plugin, a CI bot. Neither side knows or cares how the other is built. They just speak the same wire format.

This is how the web worked. HTTP doesn't tell you how to build a backend or a frontend. It tells you how the two should talk. The freedom that gave us is most of what the web turned out to be good for.

The agent era needed the equivalent. MCP, for all its dryness, is that.

why Anthropic and not OpenAI

The interesting cultural fact about MCP is that it came from Anthropic. OpenAI had, at the time, a more developed product ecosystem (Custom GPTs, the Assistants API, plugins) and a much bigger user base. The natural assumption was that whatever standard emerged would emerge from there.

What happened instead is that OpenAI's ecosystem moves were mostly product moves. Custom GPTs were a product. Plugins were a product. They were aimed at building a platform with OpenAI at the center. The Assistants API similarly assumes you'll run the orchestration on OpenAI's servers.

Anthropic's MCP move is different in shape. There's no Anthropic-specific lock-in. You can use MCP with Claude, with GPT, with Gemini, with a local model. Anthropic doesn't run any part of the stack you don't want them running. The protocol is the product, and the protocol is open.

This is partially a function of where each company sits commercially. OpenAI has more to lose by ceding the orchestration layer. Anthropic has less, and more to gain by being the one who shipped the standard. But it's also a function of taste. Anthropic's culture is more research-coded, and research culture has a healthier respect for the long-lived, boring win of a good protocol over the short-lived, exciting win of a good product.

Both bets are coherent. Both can pay. But six months in, the protocol bet is the one that's accumulating compounding interest. Every new MCP server in the wild compounds for every agent that speaks MCP. The graph of "things you can do" gets denser without anyone having to coordinate.

what MCP doesn't do

It's worth being clear about what MCP is not, because a lot of people are about to be disappointed.

MCP does not solve agent design. Your agent's prompt is still your prompt. Its planning is still its planning. Its stopping criterion is still its stopping criterion. MCP gives the agent better tool access. It doesn't make the agent smarter about using those tools.

MCP does not solve your eval problem. The hardest part of shipping an agent is knowing whether it's good. MCP doesn't help with that. If anything, it makes eval harder, because the surface area of what your agent can do is now larger.

MCP does not make bad tools good. A bad Postgres wrapper exposed over MCP is still a bad Postgres wrapper. The protocol gives you reach. It doesn't give you quality. Tool design, error semantics, idempotency, and the rest still matter as much as they ever did.

And MCP does not solve the auth and security questions. Those are bring-your-own, which is the right call (you don't want a protocol prescribing your security model) but it means every deployment has to think about it. The first MCP security incident is coming. It will probably involve someone exposing a tool with too much surface area to an LLM that talks to the wrong user. The protocol won't have failed. The deployment will have.

what comes next

The agent era is going to look more like the web than people expect. Many small servers, exposing many small capabilities, talking a common protocol. Agents as user-agents, walking the graph. The diversity of what's possible will grow faster than any single team can keep up with.

This is a good thing. It's how durable platforms always end up shaped, eventually. We just usually have to suffer through a framework era first.

MCP shortened that. Whoever was on the Anthropic team that pushed for "protocol, not framework" should be proud. It was the right call. It will be obvious in retrospect. Right now it's still slightly invisible, which is one of the marks of infrastructure that's working.