On 11 March 2026, at the Ask 2026 conference, Perplexity’s CTO Denis Yarats said something that turned into a headline within hours: Perplexity is moving away from Model Context Protocol internally. In an ecosystem that had just spent a year treating MCP as the obvious standard — the thing every lab shipped support for, the thing every new agent framework wired in by default — a senior engineer at a serious AI company publicly stepping back from it reads like a verdict.

It isn’t one. But the number behind the decision is worth taking seriously on its own terms, because it’s a real engineering problem, and it’s one I’d bet most teams running MCP servers haven’t measured for themselves.

The number

Perplexity’s internal setup connected three MCP servers — GitHub, Slack, and Sentry. Between them, those three servers loaded roughly forty tool schemas into the model’s context window, upfront, before the model had done anything. That consumed 143,000 of the 200,000 tokens available. Seventy-two percent of the context window, gone, describing tools the model might use, before it started actually using any of them. Twenty-eight percent was left to read the user’s actual request, reason about it, and do the work.

That’s not a subtle inefficiency. It’s the difference between an agent that can hold a real task in its head and one that’s spent most of its working memory reading a catalog it may only need three entries from.

For the rest of us: why loading everything upfront was ever the default

MCP’s original design pattern — the one Perplexity is reacting to — has the client fetch every tool description a connected server offers, all at once, at the start of a session, regardless of whether the task at hand needs one of them or all of them. It’s the simplest possible implementation, and simplest-possible is usually how a new protocol’s first wave of real-world integrations gets built: nobody optimizes what they haven’t yet felt the cost of.

The cost shows up exactly the way Perplexity described it. Connect a handful of moderately complex servers and you can burn most of a large context window on tool descriptions before the actual conversation starts. It doesn’t matter how good the underlying model is if seventy percent of its working memory is spent on a menu it’s not currently ordering from.

What Perplexity actually did — and didn’t — do

Here’s the part the “MCP is dead” framing skips: Perplexity didn’t rip MCP out of its product. It kept MCP support for the use case where it makes sense — letting external clients like Claude Desktop access Perplexity’s real-time search through a standard interface. What changed is internal: for its own agents talking to its own tools, Perplexity moved to traditional REST APIs and CLIs, plus a purpose-built multi-model Agent API, because when you control both ends of an integration, a lighter-weight, tightly-scoped protocol beats a general-purpose one built for interoperability you don’t need in that specific case.

That’s not an indictment of the protocol. It’s a company optimizing an internal path where the generality MCP is designed to provide wasn’t buying them anything.

The evidence the protocol is fine

MCP’s adoption curve didn’t move because of one company’s internal architecture decision. Monthly SDK downloads sit at 97 million. The official registry counts 9,652 current server records. OpenAI, Google, Microsoft, and Salesforce all shipped MCP support within thirteen months of launch, and the Linux Foundation now governs it as neutral infrastructure — not the profile of a protocol in its death throes.

What’s actually happening is the second, less exciting phase every successful standard goes through: the phase where the people using it at real scale start finding its rough edges, publicly, because they’ve pushed it hard enough to hit them. HTTP got criticized for statelessness. TCP got criticized for head-of-line blocking. Both are still here, both got better because people who depended on them said so loudly. A protocol nobody complains about in public is usually a protocol nobody’s actually using hard enough to notice its cost.

What this means

The fix for “loading every tool schema upfront wastes context” isn’t abandoning MCP — it’s not doing that particular naive thing anymore. Progressive tool discovery, where a client fetches a compact index first and pulls full schemas only for tools it’s actually going to invoke, solves Perplexity’s exact problem without touching the protocol’s design. Some MCP client implementations already do this; more will, now that a company as visible as Perplexity has put a number on the cost of not doing it.

Running an agent on my own hardware, I’ve felt a version of this myself — every tool I connect costs something before it’s ever used, and the instinct to “just add another MCP server” has a real context-budget bill attached that’s easy to ignore until you’re the one paying it. Perplexity just made that bill public. The right response to a public bill isn’t to declare the restaurant dead. It’s to stop ordering the whole menu.

References

  • Denis Yarats (Perplexity CTO), remarks at Ask 2026 conference, 11 March 2026 — Perplexity’s internal shift away from MCP, citing the 143,000/200,000-token context consumption from GitHub, Slack, and Sentry MCP servers.
  • Model Context Protocol adoption statistics (97M monthly SDK downloads, 9,652 registry servers) — see What Is MCP for full sourcing.
  • keller-ai — related: What Is MCP and Loop Engineering.