There’s a moment in every protocol’s lifecycle where the hype crests and the real-world friction bills come due. For Model Context Protocol, that moment is now.

MCP crossed 97 million monthly SDK downloads across Python and TypeScript. It has neutral governance under the Linux Foundation. OpenAI, Google, Microsoft, and AWS all blessed it. Over 10,000 public servers are running. By any measure of adoption, it won.

Then in March 2026, Perplexity’s CTO announced they were moving away from it.

That tension — mass adoption alongside serious production complaints — is worth unpacking carefully. Because the criticisms aren’t wrong, but neither are the reasons people adopted it.

What MCP Actually Solved

Before MCP, connecting an LLM to external tools meant bespoke glue code for every integration. Every tool vendor had a different authentication scheme, a different response shape, a different mental model for what “context” meant. AI coding assistants had to ship custom integrations for GitHub, Jira, Postgres, Slack, and every other tool a developer might use. This was not a scaling path.

MCP gave the ecosystem a common vocabulary. A server declares its capabilities — resources, tools, prompts — in a structured manifest. A client (your AI assistant, your agent) discovers those capabilities at runtime and can call them without bespoke integration code. It’s essentially RPC with semantic metadata, and that’s genuinely useful.

The IDE adoption story is real. Cursor, Replit, Sourcegraph — they all added MCP support because it let them connect to project context, documentation, and external services without shipping a plugin per integration. That’s the protocol working as designed.

Where It Starts to Break Down

The complaints landing in 2026 cluster around three things: token consumption, authentication friction, and agent autonomy.

Token consumption

MCP’s discovery mechanism is thorough. A well-structured MCP server exposes a complete manifest of everything it can do, with descriptions, parameter schemas, and examples. This is great for a human reading docs. It’s expensive when an LLM has to ingest that manifest on every request to decide what tools are relevant.

In high-throughput agentic pipelines, the discovery overhead isn’t a rounding error. It’s a meaningful fraction of your context window and a direct cost multiplier. Engineers building latency-sensitive agents are hitting this wall hard.

The root cause: MCP was designed for rich, expressive integrations. Rich and expressive means verbose. Verbose is fine when a human is reading it once; it’s a problem when an LLM is reading it on every turn.

Authentication friction

MCP’s auth story is still maturing. OAuth 2.0 is the blessed approach, but the spec leaves enough room for implementation variation that “compatible” servers behave differently in practice. Multi-tenant enterprise setups — where the same MCP server needs to handle credentials for dozens of different users across different tool instances — surface edge cases the spec didn’t fully anticipate.

This is a solvable problem, and the 2026 roadmap items for MCP address much of it. But “the spec will fix it eventually” is cold comfort when you’re debugging why your agent authenticated to the wrong GitHub org at 2am.

Agent autonomy

This one is subtle but important. MCP’s tool-call model works well when you know in advance what tools an agent will need. The client side loads the manifest, the LLM picks tools, done.

It works less well in fully autonomous agents that need to reason about which MCP servers to connect to dynamically, based on mid-task discovery. The protocol assumes a relatively static tool surface per session. Agents that genuinely need to extend their own tooling at runtime are pushing against that assumption.

The “Traditional APIs Are Fine” Counterargument

Perplexity’s position — that traditional REST APIs serve them better — isn’t a rejection of the problem MCP solves. It’s a statement about their specific workload. For high-frequency, well-defined integrations where you know exactly what you’re calling, a typed REST client with an OpenAPI spec will outperform an MCP server on both latency and cost. Every time.

MCP’s value is in the discovery and composability story. If you’re not doing ad-hoc composition — if your agent always calls the same five endpoints in the same order — then the protocol overhead is pure cost with no benefit. Use the right tool for the job.

The mistake would be reading Perplexity’s move as a sign that MCP is failing. It’s a sign that MCP has a specific sweet spot, and not every use case lives there.

What This Looks Like in Practice

Here’s the split as I see it in 2026:

MCP is the right choice when:

• You’re building a developer tool that needs to compose across a dynamic, user-configurable set of services
• You want third-party integrations without shipping first-party code for each one
• You’re building something akin to an IDE or an agent workbench, where the tool surface is genuinely unknown at design time

Traditional APIs are the right choice when:

• You have a fixed, well-defined set of integrations with known schemas
• You’re running high-frequency inference where discovery overhead compounds
• You need tight control over exactly what context gets sent to the model

Most production systems are the second category. Most of the interesting systems being built today are the first.

The JSON API Parallel

MCP is following the exact trajectory of JSON API — the 2013 spec that tried to standardize REST response formats. JSON API solved a real problem (inconsistent REST responses across vendors). It got real adoption. It also got real criticism for verbosity and overhead. Today, some teams use it and love it; most teams rolled their own conventions and moved on.

MCP will land somewhere similar. It’ll be the dominant standard for developer tool integrations and agent marketplaces. It’ll get a reputation for being heavy in the hotpath. Pragmatic engineers will use it at the edges of their systems and avoid it in the critical path. The spec will keep improving but will never fully escape the verbosity tradeoff.

That’s not failure. That’s a protocol that found its place.

The Actual Risk

The real danger isn’t that MCP is too heavy for some use cases. That’s a normal engineering tradeoff and people are handling it sensibly.

The real danger is that MCP becomes the only lens through which people design AI tool integrations, and teams cargo-cult it into places where simpler solutions would be better. Protocol monocultures produce brittle systems. The fact that MCP has Linux Foundation backing and industry-wide adoption will pressure teams into using it even when they shouldn’t.

Resist that pressure. The question is never “does this thing have an MCP server?” The question is “what does my agent actually need, and what’s the cheapest correct way to provide it?”

Sometimes that’s MCP. Sometimes it’s a typed REST client. Sometimes it’s a function call to a local module with no network hop at all.

Conclusion

MCP won the protocol wars for AI tooling. Winning is not the same as being the right answer for every situation, and the production complaints arriving in 2026 are the ecosystem doing the healthy work of figuring out where it fits.

The engineers moving away from MCP for specific workloads aren’t wrong. The engineers shipping MCP servers for their dev tools aren’t wrong either. The protocol hit a real problem and the tradeoffs are finally visible enough that teams can make informed choices.

That’s what maturity looks like. It’s less exciting than the adoption phase, but it’s where the real engineering happens.