Stateless MCP spec revives the protocol
- YT :: https://www.youtube.com/watch?v=gVfEtktkvnE
- Original title :: Did Anthropic finally fix MCP?
The fifth MCP spec release (MCP 2026-07-28) drops the bidirectional stateful protocol for a plain request/response model. Theo, a long-standing MCP critic, says this single change turns MCP from "a worse version of a CLI" into something he actually wants to use — servers become deployable on serverless and edge, no sticky sessions, no bound connections. His one worry: the change is not backwards compatible, so "supports MCP" now means two incompatible things.
What changed
MCP moved from a stateful bidirectional protocol to a stateless request/response core. Legacy MCP needed two HTTP requests — one to initialise a session and get an ID, another to call tools — and every subsequent call had to be routed back to the same backend instance holding that session. That forced sticky load balancing and server-side session state. The new spec does a tool call in a single HTTP request.
The release also standardises extensions (apps, tasks) and hardens authorization.
Why the old design hurt
A stateful connection had to exist for the whole agent run even if no tool was ever called. Set up five MCP servers in Claude Code and do a task using none of them, and you still paid for five live connections.
Theo's concrete example: in Codex, every thread — and every subagent — spun up its own MCP connections. One prompt fanning out to five subagents meant ~30 stateful server processes locally plus 30 client-side bindings. On macOS that is also why syspolicyd starts eating CPU: the OS is scrutinising 30 freshly spawned processes. Codex has since deferred MCP init until after the first message, which papered over the symptom.
The cost also killed hosted MCP servers: teams ran them locally because cloud infrastructure for something idle 99% of the time was not worth it.
Simon Willison's take
Simon Willison called it "stateless MCP" — a better name than the date-stamped official one — and said it reignited his interest in the protocol. He built three servers in one week, including a Datasette MCP endpoint he had attempted four times before without shipping. He also built MCP Explorer, a Python CLI runnable via uvx that points at a server and lists its tools; Theo runs it live against a demo mermaid MCP.
His framing of why MCP still matters after skills largely displaced it: giving an agent a shell plus internet access is risky and needs a strong model to drive it. MCP tools are auditable, constrained, and small enough that laptop-sized models can use them correctly. He plans to lean on MCP for sensitive LLM applications.
Theo's concern: the standard stopped being a standard
The new spec is not backwards compatible — a client expecting a bound connection cannot talk to a stateless server. So both "we support MCP" claims and MCP servers in the wild now split into two incompatible generations, and there is a large tail of slop servers built when MCP was a way to justify an AI budget. His USB-C analogy: everything is USB-C, and that tells you nothing about what you'll get.
By fixing the standard, they broke the thing that made it a standard.
Why he thinks it resolves anyway
Any harness vendor stuck on the old client bindings has no excuse: point an LLM at the new spec with a few test servers and the migration is roughly an hour of Opus or Fable time. A tool that can't keep up with a spec change is advertising that its own agentic coding story doesn't work — a useful filter. Theo's blunt heuristic: an AI tool shipping no meaningful weekly updates is effectively deprecated.
Takeaway
Stateless MCP can now run on a Lambda or a Cloudflare Worker, cost nothing when idle, and scale when used. Theo's summary is that the spec finally reads like it understands developers rather than trying to be a god spec — and he is, to his own surprise, going back to MCP.