What exactly did you reject when you said no to MCP — the protocol, or the payload? The two get collapsed into one argument constantly, and that collapse is why the whole debate has been so unproductive. One is a wire-level design question. The other is a context-budget question. They fail differently, they get fixed differently, and conflating them has let a lot of teams make architectural decisions for reasons that don’t survive a second look.
The trigger is well known by now. At Ask 2026 on March 11, 2026, Perplexity CTO Denis Yarats said the company was moving away from MCP, citing 72% context window consumption for MCP tool definitions. Within days, “MCP is dead” was the house opinion on half the timelines I read. Then on July 28, 2026, the spec shipped an update that made MCP fully stateless, with updated TypeScript, Python, Go, and C# SDKs alongside it. Cloudflare and the Model Context Protocol blog both framed it as a step change for enterprise scalability. So which is it — dead, or doing the best work of its life?
Two failure modes wearing one name
Let me separate them cleanly, because the rest of this only makes sense afterward.
The first failure mode is connection semantics. Pre-update MCP carried protocol sessions: a handshake, a negotiated state, a ticket the server had to remember. If you have ever tried to put something session-bound behind a load balancer, you already know the shape of that pain. Sticky routing, state replication, reconnect logic, a cold-start story that gets worse with every replica. This is an infrastructure problem.
The second failure mode is context economics. Tool definitions are tokens. Every tool you expose to a model is a schema the model has to read before it can decide anything. Expose enough of them and the definitions crowd out the actual task. Perplexity’s 72% figure is a statement about that arithmetic, not about handshakes. This is a reasoning-budget problem.
Both are real. They are not the same problem, and no single change fixes both.
What stateless actually fixes
The 2026-07-28 spec removes sessions altogether. No handshake, no ticket. Every request carries what the server needs to interpret it — protocol version, client identity, capabilities — bundled in. The spec also adds extensions for interactive apps and long-running tasks, which matters because “stateless wire protocol” and “stateful workflow” are not in conflict once you stop pretending the transport layer has to remember things on your behalf.
Architecturally, this is the right move and it is not a subtle one. A stateless request is a request you can route anywhere. You get horizontal scaling that works, deployment over plain HTTP without session affinity gymnastics, servers that can restart without dropping clients, and a failure model that is much easier to reason about. The long-task extension is the interesting part for anyone building agents, because it acknowledges that agent work is rarely a single call-and-response and gives that reality a defined place to live instead of leaving it to each implementer to improvise.
What stateless does not fix
Your context window. Not one token of it.
If you were serving forty tool definitions in June, you are serving forty tool definitions now. Statelessness changes who remembers what between requests; it does not change how much schema the model reads before it acts. Any team that watched the July update and concluded their context pressure was handled has misread which problem got solved.
Context pressure is an agent-design problem and it belongs to you, not the protocol. The levers are architectural: scope which tools are visible for which task, route through a planning layer that selects a small tool subset before the executing model sees anything, compress or summarize schemas, split one overloaded agent into several narrow ones with small surfaces. Perplexity’s decision reads, to me, less as a verdict on MCP and more as a company with a particular latency and token profile deciding it wanted direct control over that surface. That is a legitimate call. It is also not transferable advice.
Why enterprises never left
The quieter fact in all of this is that MCP’s value proposition for enterprises was never mainly about token efficiency. It was auth, audit trails, and governance — knowing which agent called which tool with which credentials, and being able to prove it later. Teams that need that answer do not get to skip it by hand-rolling integrations, and a stateless protocol where every request carries its own identity makes that story cleaner, not weaker.
So before you declare a position, answer three questions honestly. Is your pain deployment and scaling, or context budget? If it’s the former, the July spec is aimed directly at you. If it’s the latter, the fix is in your agent architecture and always was. And do you owe anyone an audit trail? Because that requirement outlives every protocol argument on your timeline.
MCP didn’t die. It got less interesting in exactly the way infrastructure should.
🕒 Published: