MCP's Next Spec Makes
Stateless the Standard
Syncing and recovering session state used to be the headache at scale. The MCP specification revision shipping July 28, 2026 changes that assumption at the root.
From "it runs"
to "it scales"
Since its debut, MCP (Model Context Protocol) has been built around a stateful connection between client and server: exchange an initialize handshake, then attach the server-issued Mcp-Session-Id header to every request that follows. That's no problem running a single server, but it starts to bite the moment you try to scale to multiple instances. Sticky load balancers that must remember which instance owns which request, a shared store to sync state across instances, deep packet inspection at the load balancer just to route correctly — the operational cost grew in direct proportion to how "smart" the connection was.
The official MCP blog post, "The 2026-07-28 MCP Specification Release Candidate," is described by its own authors as the largest revision since launch, and it removes exactly that: the initialize session step and the Mcp-Session-Id header are both gone from the spec. Trade press covered it in similar terms, as "Model Context Protocol prepares to break with its stateful past." This mirrors the same path stateless REST/HTTP APIs took away from cookie sessions — MCP's rite of passage from a hobbyist protocol into production infrastructure.
What disappears,
what gets added
It's not only statelessness — UI rendering, long-running tasks, and authorization all get refreshed at once.
Session management isn't the only thing being retired. The same release candidate introduces MCP Apps, an extension for rendering server-side UI inside MCP clients; a Tasks extension for long-running work; and an authorization flow that aligns with standard OAuth / OpenID Connect deployments. Meanwhile, three legacy features — Roots, Sampling, and Logging — are deprecated, with guidance to replace them with tool parameters, resource URIs or direct provider-API calls, and standard error output or OpenTelemetry streams, respectively.
Engineers and PMs
feel this very differently
The size of the benefit depends entirely on whether you operate your own MCP server.
| People who self-host an MCP server | People who just consume ready-made servers |
|---|---|
| No more sticky LB config or shared session store | No need to understand the infra at all |
| Need to audit for Mcp-Session-Id / initialize dependencies | Just wait for the client SDK to catch up |
| Operations get somewhat easier, concretely | Barely any noticeable change |
The GitHub official MCP server announcement is already living this "quiet benefit." Ahead of the final specification, on July 23, 2026, GitHub revealed that its own MCP server supports the next specification. For PMs and non-engineers who just call GitHub's server, the experience barely changes on the surface — the benefit arrives indirectly, as better reliability and latency behind the scenes. For engineers who build and self-host their own MCP servers, though, this is a direct infrastructure simplification: no session store, no sticky LB config to maintain.
Getting ready for the 07-28 cutover
Audit any self-hosted server
Check whether your self-built, self-hosted MCP server depends on initialize or Mcp-Session-Id. Worth confirming before the 07-28 cutover.
Check your client SDK's timeline
See whether the MCP client SDK you use has shipped a beta or release compatible with the new specification.
Review Roots / Sampling / Logging usage
If any tool you depend on uses the three deprecated features, plan the migration to tool parameters, resource URIs, or standard output / OpenTelemetry.
"The largest revision since launch"
is not a free upgrade.
This isn't only good news
Being "the largest revision since launch" is another way of saying the compatibility risk is large too. For developers who built servers and clients around the old stateful assumptions, this isn't a free upgrade — it's a breaking change that requires real migration work. Code that parses Mcp-Session-Id directly, or implementations that keep state per session, may simply stop working after 07-28 without changes.
A revision this large also means the ecosystem needs time to catch up, and early adopters on both the client and server side are more likely to hit bugs. If you only consume ready-made servers, none of this touches you directly — but if you self-host, it's worth treating this as more than a convenience win and keeping an eye on migration-period bug reports and SDK updates for a while.