Perplexity is walking away from MCP — and they're not wrong

MCP — the Model Context Protocol — won. In about a year it went from an Anthropic side-project to the default way every framework wires tools into agents: 97M+ monthly SDK downloads and over 10,000 public MCP servers by March 2026. It won so fast that the industry skipped a question: is it actually good in production?

Perplexity just answered. At their Ask 2026 event, CTO Denis Yarats said they're moving away from MCP internally — citing context bloat and clunky auth. When a company that lives and dies on agent quality quietly walks away from the winning standard, it's worth understanding why.

The bill is paid in context

Here's the part the "plug in everything" demos skip. Every MCP tool you attach ships its description — name, parameters, usage notes — and that text sits in the model's context window before the agent does anything. A handful of servers and it's fine. Wire up a real toolbox and, by some 2026 analyses, tool metadata can consume 40–50% of the available context window before the first useful token.

Every tool you "just plug in" is rent you pay on the context window, every single turn, whether the agent uses it or not.

And it's not only cost. A window half-full of tool definitions is a window with less room for the actual task — the conversation, the retrieved facts, the plan. It's the same context-rot problem that makes long-horizon agents fall apart, except you imported it on purpose, at startup, before the work began.

MCP isn't the villain — the "buffet" mindset is

I'm not anti-MCP. A shared protocol for tools is genuinely good; the sprawl of 10,000 servers with no real registry or trust layer is the problem, and so is the reflex to bolt on every server you might conceivably need. MCP made adding tools frictionless, and frictionless is exactly how you end up paying half your window in rent.

The fix is to treat tools the way you treat dependencies in any serious codebase:

• Curate, don't accumulate. Every tool in the window earns its place or it's gone. A tight set the agent actually uses beats a buffet it might.
• Load on demand. The agent doesn't need all 50 tool definitions for a booking task. Scope the toolset to the job — dynamically — instead of front-loading everything.
• Budget the window. Know what fraction of context your tools consume before the task starts. If it's near half, you've already lost.
• Trust is a dependency problem too. A tool description is attacker-influenced text your agent reads. Ten thousand unvetted servers is a supply chain, not a library.

The bottom line

Perplexity leaving MCP isn't "MCP is dead." It's the first big player saying the quiet part: a protocol that makes adding tools free makes adding tools too easy, and the cost lands in the one place you can't afford it — the context window.

Treat tools like dependencies, not a buffet. Curate them, load them on demand, and budget the window before the agent ever starts.