On 28 July, the Model Context Protocol published its 2026-07-28 spec. Fifth revision since launch, and the maintainers call it the largest one so far. The headline change: MCP stopped being a stateful protocol and became a stateless one.
That sentence means nothing to most people. So let me start further back.
What MCP is, in about a minute
MCP is the plug standard between AI models and everything else.
Before it existed, every AI app that wanted to read your Drive, query your database or open a Jira ticket had to write a custom integration for each one. Every model, every tool, every time. It did not scale.
MCP fixed that with one shape. You build an MCP server for your service once, and any MCP client can talk to it. Claude, Cursor, VS Code, whatever ships next year. Anthropic released it in November 2024, then handed it to a foundation, and adoption moved faster than almost anyone expected. Anthropic now puts the SDKs at around 400 million downloads a month, with over 950 servers listed in Claude's connector directory alone.
Think USB-C for AI tools. One connector instead of a drawer full of adapters.
So what actually changed
Old MCP had a memory. New MCP does not.
Under the old rules, connecting to a remote MCP server started with a handshake. Client says hello. Server says hello back and hands over a session ID. From then on, every request carries that ID, and the server remembers you between calls.
Sounds convenient. In production it was a headache.
Here is why. Say your MCP server runs on ten machines behind a load balancer, which is what any real deployment looks like. Your handshake lands on machine three. Machine three mints your session ID and remembers you. Your next request gets routed to machine seven, which has never heard of you. Error, start over.
Google's engineers wrote about deploying MCP across their own infrastructure and said they hit a hard wall on exactly this. Every workaround cost something. Pin each user to one machine and lose your load balancing. Push session state into a shared Redis and now you run a database for a protocol detail. Have your gateway crack open every request body to figure out routing and pay for it in latency. And when a machine restarted, everyone on it lost their session.
The new spec deletes the problem rather than managing it. No handshake. No session ID header. Every request carries what the server needs to know: protocol version, client info, capabilities. Any machine can answer any request, and it makes no difference which one answered last time.
Worth being precise about the claim. This is statelessness at the protocol layer, not the application layer. You can still build stateful things on top of it. HTTP is a stateless protocol and the entire web sits on it quite happily.
What that buys you
If you just use AI tools, you do nothing. Your client handles it. You should notice remote connections getting slightly faster, because a round trip disappeared, and more reliable, because a server restart no longer drops you mid-task.
If you deploy MCP servers, this is the release you were waiting for. Plain round robin works. No sticky sessions, no shared session store. You can run servers on Lambda, Cloudflare Workers, Cloud Run or Vercel and let them scale to zero when nobody is using them. GitHub shipped support early and deleted its Redis session layer outright. Their changelog put it plainly: the database writes on connect are gone, the reads on every call are gone, and nobody lost anything.
If you build MCP servers, there is work. How much depends entirely on what you built on.
The deeper cut, for people already in this
The stateless core arrives through two proposals, SEP-2575 and SEP-2567. The first kills the initialize handshake and moves protocol version, client info and capabilities into _meta on every request. The second removes the session concept and the Mcp-Session-Id header from Streamable HTTP entirely, with no deprecation window. Clean break.
If you needed state across calls, you now mint it yourself. A tool returns an explicit handle, the model passes it back as an ordinary argument, and your real state lives in Redis or Postgres keyed by that handle. Side benefit: because the handle sits in the transcript, it survives a client restart, which sessions never did.
Everything that used a held-open connection had to be rebuilt. Sampling, elicitation and roots used to depend on the server calling back down a live channel. They are replaced by Multi Round-Trip Requests. The server returns a result marked input_required with an opaque requestState, the client collects the answers, then retries the same call with the responses attached. Any instance can pick up that retry. Supabase, which runs stateless, said this is what finally lets it support elicitations at all.
The rest of the release is largely the consequences of that decision:
- Every result now carries a
resultType. Servers on older specs are treated ascomplete. - Every POST carries
Mcp-MethodandMcp-Nameheaders, so gateways can route, rate limit and audit without parsing the body. - List results carry
ttlMsandcacheScope, borrowed straight from HTTP cache semantics. Setpublicon a per-tenant list and you have shipped a data leak, so be careful there. - The GET endpoint and
resources/subscribeare gone, replaced by a singlesubscriptions/listenstream you opt into per notification type. - Resumability is gone. No
Last-Event-ID, no event IDs. A broken stream loses the in-flight request and you reissue it. Durability moved to the Tasks extension, which also left core and now works by polling. - Roots, sampling and logging are deprecated, along with the old HTTP+SSE transport. There is finally a formal deprecation policy with a minimum twelve month window, so nothing disappears overnight.
- Auth got stricter. Issuer validation is now required, and Client ID Metadata Documents start replacing dynamic client registration.
All four Tier 1 SDKs shipped support on publication day. TypeScript split into separate server and client packages and ships a codemod. Python renamed FastMCP to MCPServer. Go barely changed.
The part nobody should skip
Statelessness does not remove work. It moves it onto you.
There is no session to authenticate once, so every request needs authenticating. Akamai's threat researchers flagged the obvious consequences: client-controlled _meta fields that carry no signature, secrets accidentally mapped into headers and therefore visible to every proxy and log along the path, and cheap task creation as a denial of service vector. Their summary is fair. The security boundaries are now entirely dependent on how each developer implements them. They also sell products in this space, so weigh it accordingly.
The migration itself is real. The Register's framing was blunt about homebrew implementations facing a slog, and MCP's lead maintainer said out loud that a lot of the things that made MCP are gone. He is right. If you wrote your own transport, budget a week and expect surprises. Old clients and new servers cannot talk without deliberate fallback on one side.
And the fairest criticism going around: if a remote MCP server now looks like a normal stateless HTTP service, what is MCP actually for? The honest answer is that the value was never the transport. It is discovery, tool schemas and a shared authorization story. This release just stops the transport from being the thing you fight.
Where I land
The framing I keep coming back to is that this took eighteen months, not one release. Streamable HTTP made stateless servers possible back in March 2025. This spec made stateless the only model. The gap between those two dates is the gap between something being technically supported and being how it actually works.
One vendor survey puts 41% of software organizations running MCP in production in some form. That is the reason the protocol had to grow up. You cannot ask that many teams to run Redis for a handshake.
The interesting problems in MCP are no longer transport problems. They are authorization, metering and attribution. Working out who is allowed to call what, and who pays.
That is what a protocol looks like when it stops being a demo.
Drawn from the MCP 2026-07-28 spec and its SEP-2575 and SEP-2567 proposals, Google's and GitHub's engineering write-ups on running it, Akamai's threat research via SecurityWeek, Supabase's and Anthropic's release notes, The Register's coverage, and one vendor's production-adoption survey. A snapshot as of August 9, 2026. Specs move, so check modelcontextprotocol.io before you quote me on a header name.