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

MCP won the standards war so fast that almost nobody stopped to ask whether it's actually good in production. Then Perplexity's CTO said out loud they're moving off it internally — because tool metadata can eat 40–50% of your context window before the agent does a single useful thing. The 'just plug in 50 MCP servers' dream collides with context economics. Tools are a dependency, not a buffet.

- **Author:** Fedor Chishchin
- **Published:** 2026-07-01
- **Tags:** architecture, agents, mcp
- **Source:** https://fedorthinks.com/blog/perplexity-is-leaving-mcp

---

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](https://www.digitalapplied.com/blog/mcp-adoption-statistics-2026-model-context-protocol).
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](https://thenewstack.io/model-context-protocol-roadmap-2026/) — 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](https://www.digitalapplied.com/blog/mcp-adoption-statistics-2026-model-context-protocol)
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](/blog/doubling-the-task-quadruples-the-failure), 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](/blog/your-agent-trusts-the-tool). 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.**