MCP's stateless revision splits the protocol and makes vendor support claims ambiguous

The phrase "supports MCP" has quietly stopped meaning one thing. According to a post on dev.to, a spec revision dated 2026-07-28 removed the Model Context Protocol's session model, and as a result two incompatible generations of the protocol are now running in production at the same time — with nothing in a vendor's marketing copy indicating which one a given product actually speaks.

What the revision changed

The author calls the revision the biggest change to the protocol since it launched, roughly a year earlier. Under the old design, a client opened a connection by calling initialize, received a session ID, and stayed pinned to a single server instance. Scaling that model required sticky routing or a shared session store such as Redis, which made every request depend on the store, tied sessions to instance lifetimes, and made load balancing a persistent problem.

After the revision, every request carries what it needs. There is no handshake, no session and no affinity requirement: a plain round-robin load balancer in front of stateless servers works, and restarting a server stops being an event. The revision also tightened authorization toward OAuth and OIDC conventions, added a deprecation policy, and introduced extensions for long-running work and server-rendered UIs — but the post argues statelessness is the change that rewrites infrastructure assumptions.

Why the checkbox got ambiguous

The stakes are larger than protocol hygiene because of the protocol's reach. The post claims the tier-one SDKs are logging on the order of half a billion downloads per month, with the TypeScript and Python SDKs past a billion lifetime downloads each. An ambiguous compatibility claim on a spec at that scale is an ambiguous claim multiplied across a very large ecosystem.

The practical problem is that the change is breaking and the ecosystem is straddling it. Some clients still run older SDKs; some servers still expect the old handshake. "Supports MCP" can mean either revision, and the phrase itself gives no clue which — which the author likens to buying a USB device with no marking on the connector.

How to tell which MCP you are talking to

The post offers a diagnostic-first checklist:

• Probe for initialize before anything else. An old-revision server answers; a new-revision server does not expect the call. The author says this single probe sorts an entire vendor list.
• Drop sticky routing only for new-revision servers. Round-robin balancing is the point of the redesign, but old-revision servers still need sessions.
• Re-verify authentication flows across both generations. A client that works against new-revision servers can fail silently against old ones, because the handshake it skipped was load-bearing for the old auth path. The failure looks like your bug but is actually a version mismatch — where, in the author's words, the afternoons go.
• Pin SDK versions and record which revision each server speaks. The ambiguity does not resolve itself; it gets managed, ideally in a simple two-column list of servers and revisions.

The upside

The author is broadly positive about the direction of the change: stateless MCP is simpler, and the pain is transitional rather than architectural — a distinction the author notes is rare for breaking migrations. The post cites Simon Willison's argument that tooling speaking MCP is auditable in a way a shell-enabled agent is not, and that a stateless core lets the protocol scale on ordinary infrastructure most ops teams already run. The redesign also moves MCP closer to how command-line tools have always worked: run a command, get output, move on.

Why it matters

The old generation is not going away quickly. The author expects some hosts to remain on old SDKs for a long time, making a straddled ecosystem the normal condition rather than a passing phase. For anyone building or buying agent integrations, the actionable shift is to stop asking vendors whether they support MCP and start asking which revision they implement — and to verify with a probe rather than a label, because support matrices rot and further spec revisions are coming. Even when a vendor names its revision, the post argues, someone still has to check.