The Model Context Protocol became AI's USB-C, and that standardization has a cost
In March 2026, Anthropic reported that the Model Context Protocol's SDK had crossed 97 million monthly downloads. Every major AI provider — Anthropic, OpenAI, Google, Microsoft, AWS — now ships native MCP support, and public server counts run past 10,000. By any download metric, MCP has already won the standardization fight for connecting AI agents to tools and data. But winning the download count and solving the integration problem are turning out to be two different things.
MCP is becoming infrastructure the way USB-C became infrastructure: nearly universal, broadly beneficial, and still capable of plugging in a cable that technically fits but doesn't actually do what you expected.
Why MCP Won So Fast
Before MCP, every AI application that wanted to connect to external tools — a database, a calendar, a code repository — needed a custom integration. Each new data source meant another bespoke connector, built and maintained separately by every AI vendor that wanted to support it. MCP standardized the interface: one protocol an AI model can use to discover and call tools, regardless of which model or which tool is on the other end.
That's a genuinely valuable problem to solve, which is why adoption moved so fast. Anthropic donated MCP to neutral governance in December 2025, placing it under the newly formed Agentic AI Foundation — a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI. Neutral governance removed the biggest objection competitors would otherwise have had to standardizing on another lab's protocol.
The Fragmentation Hiding Inside the Standard
Here's the catch: MCP standardizes the shape of the interface, not every implementation detail underneath it. Transport mechanisms diverge — some MCP servers run over stdio, others over HTTP with server-sent events. Authentication approaches diverge. Permission models diverge. The practical result, according to analysts tracking the ecosystem, is that "build once, use anywhere" degrades into "build once, then test separately against every client you actually plan to support."
This matters more than it sounds like it should, because the entire value proposition of a standard is that you don't have to do per-client testing. If you're building an MCP server and need to verify it behaves correctly across Claude, ChatGPT, Gemini, and Copilot clients — with different transport and auth assumptions in each — you've reintroduced a meaningful chunk of the integration tax MCP was supposed to eliminate.
Security Is the Sharper Edge of the Same Problem
Fragmented permission models aren't just an engineering annoyance — they're a security surface. An MCP server that assumes one client's permission model may behave unsafely when called by a client with looser assumptions about what a tool is allowed to touch. The first half of 2026 brought exactly the kind of security issues that tend to surface once millions of people depend on something: the growing pains of a standard whose enterprise-grade authentication story is still catching up to its download numbers.
Industry surveys suggest only a minority of organizations — roughly 41% in one count — have gotten MCP servers successfully into production, well below the adoption implied by the download figures. That gap between "downloaded the SDK" and "running it safely in production" is where the fragmentation costs actually land.
What to Watch Instead of Download Numbers
If you're evaluating MCP for your own stack, the download count and server count are the wrong metrics to anchor on — they measure enthusiasm, not interoperability. Three more useful signals:
Transport and auth compatibility across the specific clients you need. Don't assume an MCP server that works with one AI provider's client will behave identically with another's. Test against your actual client list before committing.
Whether the Agentic AI Foundation ships a conformance test suite. A neutral governance body that only publishes a spec, without a way to verify implementations against it, will not close the fragmentation gap. Watch for tooling, not just documentation.
How your permission model degrades under a looser client. If a tool server is going to be called by clients you don't control, design its permission boundaries assuming the strictest client isn't the only one that will connect — because production incidents in 2026 have already shown that assumption fails.
MCP solved the problem it set out to solve — a universal discovery and invocation layer for AI tools — faster and more completely than most standards efforts manage. The unfinished work is the part that was always going to be harder: making "universal" actually mean interchangeable, not just widely installed.