You said no MCP. Loudly.
I remember the week. March 11, 2026, Ask 2026, Perplexity CTO Denis Yarats says the company is moving away from MCP. He cites a number that made every bot builder wince: 72% of the context window eaten by MCP tool definitions. Within days the timeline had its verdict ready. MCP is dead.
I build bots for a living. I had three agents in production at the time, all wired through MCP servers. So I did what you probably did — opened the token counter, looked at my own tool definitions, and felt that specific kind of dread where you suspect the loud people on the internet might be right.
The 72% problem was real
Let’s be fair to the criticism, because it wasn’t noise. If tool definitions consume 72% of your context window before the user types a single character, you don’t have an agent. You have a very expensive manifest file with a chat box attached.
Every builder who has shipped a multi-tool agent knows this shape of pain. You add a server for your database. Another for your docs. Another for your ticketing system. Each one shows up with its full schema, every parameter described in careful prose, and the model has to read all of it on every single turn. The protocol that was supposed to make tool use simple became the single largest line item in your token bill.
So when Yarats said they were walking away, a lot of us nodded. Not because we hated MCP, but because we’d all personally met the thing he was describing.
What actually happened next
MCP didn’t die. It got rebuilt.
The 2026-07-28 specification removed protocol sessions entirely. No handshake. No session ticket to hold onto. Every request now carries what the server needs to understand it — protocol version, client identity, capabilities — bundled in. The spec, SDKs for TypeScript, Python, Go, and C#, all shipped together.
If you’ve ever tried to deploy a stateful MCP server behind a load balancer, you know exactly why this matters. Stateful protocols and horizontal scaling are old enemies. You end up pinning sessions to instances, or standing up a shared store just to remember who’s talking to whom, or quietly running one box and hoping nobody notices. Stateless requests go anywhere. Any instance, any region, any cold-started function. Cloudflare’s write-up on the new generation of MCP leans hard on this, and the official spec blog frames it as a leap for enterprise AI scalability.
The update also adds extensions for interactive apps and long-running tasks. For anyone who has hand-rolled a polling loop because their agent needed to kick off a ten-minute job, that’s the kind of boring improvement that quietly deletes code from your repo.
Why enterprises never left
Here’s the part the obituary posts skipped. The teams making the most noise about dropping MCP were optimizing for one thing: tokens per turn. Real constraint, fair priority.
Enterprises are optimizing for a different list. Auth. Audit trails. Governance. When your agent touches customer records, somebody needs to answer who called what, with which credentials, and when. MCP’s value proposition there was never about token efficiency. It was about having a standard way to answer those questions instead of inventing one per integration.
That’s why “MCP is dead” and “enterprises are standardizing on MCP” were both true at the same time, and why reading either one in isolation would have led you to a bad architecture decision.
What I’d actually do now
If you shelved MCP in the spring, this is a reasonable moment to look again. A few things I’d check in your own stack:
- Measure your tool definition overhead as a percentage of context. Not vibes, actual numbers. If you’re nowhere near 72%, the thing that scared you off may not apply to you.
- Audit how many servers your agent loads on every turn versus how many it actually needs. Breadth of tools is the cost driver.
- If you built session-pinning workarounds for deployment, the stateless spec likely lets you delete them. That’s real code off your maintenance bill.
- Pull the updated SDK for your language and read the migration surface before you plan anything bigger.
The actual lesson
The protocol took a legitimate, specific, quantified criticism in March and shipped a structural answer in July. That’s not a protocol dying. That’s a protocol working the way open specifications are supposed to work.
The failure mode wasn’t MCP. It was how fast a single valid complaint from one company turned into a declaration that an entire approach was finished. Builders who threw out working integrations on the strength of a hashtag spent the summer rewriting plumbing for no reason.
Benchmark your own system. Read the spec. Decide from there. The timeline is not your architecture review.
🕒 Published: