MCP Just Went Stateless. That's the Story, Not the Deadline.

Systems Intelligence · systemsintel.dev · July 16, 2026

Your feed says migrate your MCP servers before July 28 or they break. That’s wrong — and the wrongness is the interesting part.

You’ve seen the checklist. Someone forwarded it, someone else reposted it, and now it’s sitting in three of your channels with a countdown attached. Patch these headers, remap these error codes, do it before the 28th or your integrations fall over.

If you run remote MCP servers in production, that message is built to make your stomach drop. So let’s start with what’s true, because plenty of it is.

This is the largest revision of the protocol since launch. The maintainers say so in as many words: the release candidate locked May 21, and the final spec publishes July 28 (blog.modelcontextprotocol.io). The changelog is long and none of it is cosmetic. OAuth hardening. JSON Schema 2020-12 for tool schemas. W3C trace context. HTTP+SSE transport deprecated. This is a genuine reset, and treating it as a non-event is its own kind of malpractice.

So the deadline is real. What’s fake is the cliff.

Real vs. theater

Here’s the line nobody forwarding the checklist is drawing for you: the day the news breaks is not the day anything breaks.

MCP’s lifecycle policy guarantees at least twelve months between deprecation and removal. Servers built on the 2025-06-18 and 2025-11-25 revisions keep working after July 28. Nothing gets deleted day one. And if you’re running local STDIO servers, most of this doesn’t reach you at all. The disruptive changes are a remote-HTTP concern, because that’s where the problem they solve actually lived.

There is a real reason to move: you want to be current before the runway closes, and you want to reason about the change while it’s fresh instead of under duress a year from now. That’s a deadline for adoption. It is not a fire alarm.

The checklist collapses those two things into one. It takes a protocol reset with a year of runway and repackages it as a config patch due Tuesday. And once you can see that move, you can see what it’s hiding, which is the only part that actually matters.

One change takes state out of the protocol

Sessions are gone.

That’s the change that leaves every request standing on its own, and it’s buried on page four of every checklist because it can’t be written as a step.

Two proposals do the work. SEP-2567 removes sessions. SEP-2575 removes the initialize/initialized handshake. Identity and capabilities now travel through _meta, with a new discovery method replacing the old negotiation. WorkOS, writing on the authentication changes, puts it plainly: the protocol is going stateless. Any request can now land on any server instance.

Sit with that for a second, because it is not a version bump. It’s an architecture decision someone already made for you.

A stateful protocol lets you assume continuity. The same client talks to the same instance, the handshake establishes who they are, and each exchange after leans on that. Stateless removes the assumption. Every request arrives cold. Which means the questions you thought were settled are open again. Where does state live now? How do you establish identity per-request instead of per-session? How does a load balancer route traffic it can no longer tie to a session?

The spec answers that last one directly. The Mcp-Method and Mcp-Name headers become mandatory (SEP-2243) so a load balancer can route without cracking open the request body. That isn’t a chore to tick off. That’s the protocol telling you it now expects to run behind infrastructure that treats every call as independent. Caching moves the same direction: ttlMs and cacheScope appear on results because in a stateless world the server can no longer remember what it already told you.

Read those details as tasks and you’ll patch them and move on. Read them as evidence and they say the same thing in unison. The model of what an MCP connection is just changed underneath you.

The specimen

The forwarded checklist is worth keeping: as a specimen, not a map.

It optimizes for looking responsive. Fifteen bullets, a deadline, a sense of motion. What it can’t do is tell you why any of it is happening, because the “why” isn’t a task you can complete. The posture treats a protocol reset as a config scramble, and a config scramble has one seductive property: you can finish it. You can close the tickets and feel done, having never once asked what stateless does to your routing, your identity model, or your cache.

That’s the trap. Migrate reactively to a list and you’ll rebuild your integration twice. Once now, in a hurry. Again in six months, when you realize removing sessions quietly rewrote your entire state and routing model while you were treating it like a header change.

One more for the “why” pile, since it also isn’t a step: Akamai has flagged that the new MCP Apps feature introduces a stored-XSS class of risk, and that cheap task creation opens a denial-of-service vector. Security researchers are reading the changelog as architecture. The checklist is reading it as chores.

The actual question

Adopt while it’s current. The reason isn’t to dodge a cliff that doesn’t exist. It’s that reasoning about a stateless protocol is the work, and doing it deliberately now costs less than doing it reactively later.

The deadline on your feed is answering the wrong question. The real one was never did I patch the headers before the 28th. It’s does my architecture still hold when any request can hit any instance and nothing remembers the last one.

One question before the next issue: where does your MCP server keep state today: in the session, in a database, or somewhere you’d have to go check? Reply with one sentence. I’m compiling how people answer, because it predicts almost exactly how much the stateless shift is going to cost them.