Seventy-two percent. That’s how much of the context window Perplexity said MCP tool definitions were eating before the model got around to doing any actual work. CTO Denis Yarats dropped that number at Ask 2026 on March 11, and within days the obituaries were being drafted. “MCP is dead” became the take of the week.
I want to be clear about what I think of that reaction, because I’ve been reviewing agent tooling long enough to recognize the pattern. One large company announces they’re moving off a protocol, cites a genuinely ugly metric, and the internet decides the protocol is a corpse. Then four months later a spec update lands and everyone quietly updates their SDKs.
What Perplexity actually said
They said they were moving away from MCP, and they said why: token consumption. That’s it. That’s the fact. Not that MCP was poorly designed, not that the industry should abandon it, not that there’s a better standard waiting in the wings. A company with a specific product shape and specific cost pressures found that loading tool definitions into context was too expensive for them.
If you run a search product where every millisecond and every token is a margin line item, 72% overhead is indefensible. I’d have made the same call. But Perplexity’s cost structure is not your cost structure, and treating their engineering decision as a universal verdict is lazy thinking.
What gets lost in the dunking is that the complaint was about efficiency, not about whether the problem MCP solves is real. Those are very different critiques. One gets fixed by a spec revision. The other would require starting over.
Then July happened
The 2026-07-28 specification removed protocol sessions entirely. MCP is now fully stateless. No handshake, no session ticket. Every request carries what the server needs to understand it — protocol version, client identity, capabilities — bundled in.
The release shipped alongside updated TypeScript, Python, Go, and C# SDKs. It improves HTTP deployment and adds extensions for interactive apps and long-running tasks. Cloudflare and Google Cloud both published on it, with the framing centered on stateless architecture and enterprise scalability.
Statelessness is not a cosmetic change. Sessions are the reason distributed deployment of MCP servers was annoying. Sticky routing, session affinity, state that has to live somewhere and get cleaned up when a client vanishes. Remove sessions and your MCP server becomes an ordinary HTTP service you can put behind a load balancer and scale horizontally without thinking hard about it.
That’s the kind of fix that reads as boring in a changelog and shows up as a real difference in your ops bill.
The part nobody writing hot takes cares about
MCP remains relevant for enterprises because of auth, audit trails, and governance. Those three words are why the protocol will outlive the discourse about it.
If you’re a solo developer wiring an agent to three APIs, you don’t need a protocol. You need three API clients and an afternoon. The calculus changes completely when you’re an organization that has to answer questions like:
- Which agent called which tool, and when
- Who authorized that agent to have access in the first place
- What does the audit record look like when compliance asks for it
- How do we revoke access across every agent at once
Those are not fun problems. They’re also not optional problems. Every company that has rolled its own integration layer eventually rebuilds a worse version of what a standard protocol gives you, and they do it under deadline pressure with no documentation.
My actual read
MCP is not dead. It’s evolving, which is the least exciting and most accurate thing you can say about any piece of infrastructure that’s being used seriously.
The honest version of the Perplexity story is that a specific efficiency problem got identified publicly by a credible engineering voice, and the protocol changed in a way that addresses deployment and scalability concerns. That’s how standards are supposed to work. Someone hits a wall, says so loudly, and the spec moves.
What I’d push back on is the reflex. The AI tooling space has developed an unhealthy appetite for declaring things dead, and it’s reached a point where I treat “X is dead” posts as a signal that X is about to get interesting. The declaration arrives fastest for the technologies that are being adopted widely enough to generate real complaints.
If you shipped something on MCP before March and spent the spring wondering whether you’d bet wrong, you didn’t. If you were waiting for the dust to settle before building, the stateless spec and the four updated SDKs are your signal to start.
And if you said no to MCP on the strength of a hot take, go read the July spec. The thing you rejected isn’t the thing that exists now.
🕒 Published: