Why does a stateless protocol core matter to an AI tool server you didn’t design to scale?
The Model Context Protocol’s 2026-07-28 release candidate moves protocol sessions out of the centre of Streamable HTTP. The release notes describe a stateless core that scales on ordinary HTTP infrastructure: a request carries what’s needed to route it, so a server can sit behind normal load balancing without a sticky session store remembering which process a client last spoke to. That does not make every MCP application stateless. It makes the protocol layer easier to scale, retry and observe.
This article reviews the official release notes and SDK migration documentation checked on 22 September 2026. It does not report running an MCP server at scale.
What moved out of the protocol core
Before this revision, an MCP client and server could build up affinity: a session identifier, a handshake, or a server-initiated prompt tied to one connection. The stateless core removes that assumption from the protocol layer itself. A server can now be one of several interchangeable processes behind a load balancer, and a dropped connection does not have to mean a broken session. The release also describes cache metadata, operation headers and trace context, which matter to anyone trying to follow one logical tool call across several services rather than one long-lived socket.
Stateless does not mean without state
The distinction is practical. A server can still keep business state in a database, a queue or a cache. What it should stop doing is depending on one specific process remembering that a client spoke to it five seconds ago. Move that assumption into a store you can inspect, replicate and fail over, and the request itself becomes easier to retry, cache and trace independently of which server instance handled it.
What a migration actually requires
Removing session affinity is not free for existing integrations. Code that relied on a handshake, a session identifier or a server pushing an unprompted message can behave differently once the transport no longer guarantees the same process handles every request. The TypeScript SDK’s migration guide documents revision-specific authorisation requirements alongside the transport change. I would treat it as a version matrix: which client version, which server revision, and which transport assumptions actually held before you touched anything. Test the transport in isolation before touching business logic on top of it.
Why removing affinity is the bigger improvement
It is tempting to read protocol updates only for new capabilities. Here, removing a hidden dependency is arguably the more consequential change. A stateless core turns a clever local integration, tuned to one process and one connection, into something that can survive a second instance, a failed request, and a trace someone can actually follow after the fact. That is a smaller headline than a new feature, and a bigger deal for anyone who has to operate the thing in production.
Follow the English RSS feed for the next article.
About the author: see my portfolio and my agency, Bimbi Digital.