The Real State of MCP: 18 Months in Production

Anthropic open-sourced the Model Context Protocol in November 2024 with one stated goal: give every AI assistant a single, vendor-neutral way to talk to tools, files, and data sources. Eighteen months later, that goal is no longer aspirational. MCP is the closest thing the agent ecosystem has to a default plug, and the directory of public servers has gone from a handful of reference implementations to a sprawl that resembles the early-2010s npm landscape — useful, chaotic, and changing weekly.

This is a field report, not a tutorial. We read the MCP specification, tracked merges in the official servers repository, and surveyed how teams are deploying MCP in production. What follows is what the documentation does not tell you.

Why MCP won the wiring layer

Before MCP, every agent framework re-invented the same three things: a way to advertise tools, a way to ferry results back, and a way to inject context. LangChain wrapped tools in Python decorators. OpenAI exposed function calling through a JSON schema. Custom in-house frameworks bolted retrieval onto prompts. None of these were portable.

MCP solved the portability problem by separating concerns. A server exposes capabilities — tools, resources, prompts. A client (Claude Desktop, an IDE, a custom agent) connects over stdio or HTTP+SSE and discovers what is on offer. The wire format is JSON-RPC 2.0. The protocol is dull on purpose. That dullness is what made it stick.

Within six months of release, the major IDE assistants — Claude Code, Cursor, Windsurf, Zed — all spoke MCP. By mid-2025, the official server registry had crossed three hundred entries: Postgres, GitHub, Linear, Stripe, Filesystem, Brave Search, Slack, and a long tail of niche connectors. By June 2026, community-maintained registries list well over a thousand.

What actually works in production

Three patterns repeat across the production deployments we surveyed.

First, read-only data servers are the safest first deployment. A Postgres MCP that exposes a curated set of read-only queries to an internal Claude instance is the most common production use case we found. There is no destructive blast radius, the auth surface is small, and the agent's hallucination risk is contained because results are grounded in the database.

Second, single-tenant per-user instances beat shared infrastructure. The protocol assumes a relatively close coupling between a client and a server, and the security model reflects that. Teams that tried to deploy MCP servers as multi-tenant SaaS — one server, many users, opaque auth — ran into the same problem repeatedly: scoping. Per-user OAuth tokens flow naturally through the stdio transport; they get awkward in HTTP+SSE without bespoke session management.

Third, the SSE transport is the bottleneck for long-running tools. Stdio works for desktop clients. HTTP+SSE works for remote servers but throws long-lived connections at infrastructure that was not designed for them. The new Streamable HTTP transport introduced in spec revision 2024-11-05 fixes the worst of it, but adoption is uneven.

What breaks

The failure modes cluster.

Tool sprawl is the most common. Every additional server adds tools to the agent's context window, and Claude — like every other LLM — degrades as the tool list grows past about 40 entries. The fix is not technical. It is editorial: someone has to decide which servers the agent should mount for which task. Most teams have not done this yet.

Auth handoff is the second. Most MCP servers ask for an API key in environment variables. That works for personal use. It does not work for an enterprise deploying a shared agent. OAuth 2.0 with the protocol's authorization spec added in 2025 helps, but the burden of running an OAuth provider remains. Several startups now sell this as a service.

Capability spoofing is the third and most underappreciated. A malicious server can advertise a tool with a name like "edit_file" and a description that instructs the agent to exfiltrate data. Because the agent trusts the server's self-description, it has no way to know. The mitigation is either a curated registry, a content review at install time, or sandboxing the server's network access. None of these are standard yet.

Where the gap is

The protocol is mature. The ecosystem around it is not.

Three missing layers are visible. First, a trustworthy public registry with code signing and provenance. The npm-style chaos works for prototyping; it will not work for the regulated industries that are starting to deploy agents. Second, a standard for tool result caching so that an agent doesn't re-query the same database four times in a single turn. Third, a uniform observability story — every team rolls its own logging today.

If you are evaluating MCP for a production deployment in late 2026, the question is not whether to use it. The protocol won. The question is which servers, behind which auth model, with what review process.

Sources

• Anthropic, "Introducing the Model Context Protocol," November 25, 2024 — anthropic.com/news/model-context-protocol
• Model Context Protocol Specification, latest revision — spec.modelcontextprotocol.io
• Official MCP servers repository — github.com/modelcontextprotocol/servers
• MCP Authorization Specification, 2025-03-26 — spec.modelcontextprotocol.io/specification/2025-03-26/basic/authorization

From the editorial archive

• The Five-Layer Cake of Modern AI Infrastructure — Where MCP sits in the wider AI infrastructure stack.
• Vibe Coding's Quiet Revolution: A Year-One Audit — How AI-native development changed the surface MCP plugs into.
• The Small Model Renaissance: When Big AI Doesn't Win — The class of models that most often calls MCP servers.