The Model Context Protocol published a specification dated 2026-07-28, following a release candidate under the same date. Ahead of it, The Register's coverage on July 23 framed the change as the protocol preparing to break with its stateful past. Roughly the same window brought v2.0 of the official MCP C# SDK from Microsoft. The spec itself is a month old; the reason it's worth attention now is that SDK majors are the point where a protocol change stops being a design discussion and starts being a migration.
I'd treat the headline framing as directional and read the spec changelog before planning work — I could not verify the mechanics in detail, and "stateless" covers a wide range of possible requirements.
What breaks in a knowledge connector
Most retrieval-serving MCP servers written in the last eighteen months quietly assume a long-lived session. The patterns are familiar: an open stream with a session ID, pagination cursors held in a process-local dict, a per-session cache of resolved ACLs so you don't re-hit the permissions API on every `search` call, an embedding cache keyed by conversation, a reranker budget tracked across turns. None of that is in the tool schema. It lives in RAM, and it works right up until the process restarts.
Stateless serving removes that hiding place. The upside is real and boring: horizontal scaling behind a plain load balancer, no sticky routing, no session-affinity bug that only appears during a deploy, failure recovery that costs one retry instead of a re-index. The cost is that every piece of state you were carrying implicitly now needs a name and a home. Cursors become opaque tokens the client hands back. Authorization gets resolved per request, which means the permissions path becomes a hot path and you need to decide what you're willing to cache and for how long — a genuine correctness question in enterprise search, where a stale ACL is a leak, not a latency problem.
Retrieval is stateful in practice even if the transport isn't. The state goes to a store you operate, or it goes into the context window as client-held tokens. The first costs you a Redis or Postgres dependency and a TTL policy; the second inflates every request and puts your pagination internals in front of a model that may mangle them. Pick deliberately.
Who should care: teams running MCP servers over Confluence, Drive, ticketing, or a warehouse in production, and platform teams who now own version negotiation between clients and servers that will be on different spec dates for months. Anyone prototyping locally over stdio can ignore this entirely.
Concrete next step: grep your server for anything keyed by session ID, and test a restart mid-conversation. If retrieval can't resume from the client's last token alone, you have migration work whose size you don't yet know.