MCP Went Stateless This Year. Your "Supports MCP" Checkbox Is Now a Lie.

"We support MCP" used to mean something specific. This year it became ambiguous, because there are now effectively two MCPs, and most vendors aren't telling you which one they mean.

The protocol is a year old and already halfway through its own identity crisis.

If you build or buy anything agent-adjacent, this is your migration, whether or not anyone scheduled it. And nobody scheduled it.

What changed

The 2026-07-28 spec revision is the biggest change since the protocol launched, and the headline is: the session is gone.

Before: a client called initialize, got a session ID, and got pinned to one server instance. Scaling meant sticky routing or a shared session store like Redis, which meant every request depended on the store, one instance dying took its sessions with it, and load balancing was a permanent geometric pain.

After: every request carries what it needs. No handshake, no session, no sticky routing. A plain round-robin load balancer in front of stateless servers, and a server restart stops being an event.

There's more in the revision, authorization tightened up toward OAuth and OIDC conventions, a deprecation policy, extensions for long-running work and server-rendered UIs. But statelessness is the one that rewrites your infrastructure assumptions.

Why it matters beyond hygiene: the scale signal is absurd. The protocol's own tier-one SDKs are logging on the order of half a billion monthly downloads, TypeScript and Python past a billion lifetime each. "Supports MCP" is no longer a boutique claim. Which cuts both ways, because an ambiguous checkbox on a spec that large is a very big ambiguous checkbox.

The migration nobody budgeted

Here's the part that will eat afternoons: the change is breaking, and the ecosystem is straddling it.

Two generations of MCP are live in production right now. Some clients are on old SDKs. Some servers expect the old handshake. "We support MCP" can mean either revision, and nothing in the phrase tells you which. For a while, buying agent tooling is going to be like buying a USB device with no marking on the connector.

The checklist that saves the migration:

Find the revision before anything else. Probe for initialize and see what happens. Old revision answers, new revision doesn't expect it. This one diagnostic sorts your whole vendor list.

Drop sticky routing on new-revision servers. Round-robin is the whole point. If you're on old-revision servers, you still need sessions and this paragraph doesn't apply yet, and knowing which side of that you're on is the actual work.

Re-verify auth flows on both generations. This is where the afternoons go: a client that "works" against new-revision servers fails silently against old ones, because the handshake it skipped was load-bearing for the old auth path. The failure looks like your bug. It's a version mismatch.

Pin SDK versions and record which revision they speak. The ambiguity doesn't resolve itself, it gets managed. A two-column list, servers and their revision, is the entire artifact.

The part I actually like

I keep this honest by noting what's genuinely good here: stateless MCP is simpler, and the direction is right. Simon Willison made the case when the spec landed, tooling that speaks MCP is auditable in a way a shell-enabled agent isn't, and the stateless core means the protocol scales on boring infrastructure that every ops team already owns. It moved toward how CLIs have always worked: run a command, get output, move on.

The pain is transitional, not architectural. That's rare and worth saying out loud, because most breaking migrations are pain all the way down.

What I can't claim

The old generation isn't going anywhere fast. Some hosts will be stuck on old SDKs for a long time, and straddling is going to be the normal condition, not a phase. Plan for living in ambiguity, not for graduating out of it.

And a checkbox is still a checkbox: even when your vendor names their revision, someone has to verify, because support matrices rot and spec revisions keep coming. Trust the probe, not the label.

Stop asking vendors "do you support MCP." Ask "which revision," and keep the probe in a script, because the answer changes faster than the docs.

Which revision is your MCP server actually speaking, and when did you last check rather than assume?