MCP’s biggest update removes the machinery many servers were built around
The New Stack Janakiram MSV ● Covered by 7 sources
MCP is dropping sessions and handshakes in its biggest update, final spec lands July 28. Servers can now run like plain web services, no special plumbing needed.
Based on reporting by The New Stack, Janakiram MSV — read the original for the full story.
Summary, retelling and take written by AI under human oversight; images are AI-generated illustrations. How we work · Report an error
The Model Context Protocol's lead maintainers froze the release candidate for its biggest overhaul on May 21, with the finished specification due July 28. On paper, the changelog reads like a demolition: sessions gone, the initialization handshake gone, three core features marked for deprecation. Read the reasoning behind it, though, and it's less demolition than eviction — MCP is handing jobs back to infrastructure that already knows how to do them.
The root problem traces back to MCP's original shape. It was built for a desktop app talking to a local process over standard input and output, where a startup handshake barely registered against a connection that stuck around for a long time. Once servers started running remotely and at scale, that same handshake turned expensive. A server would mint an Mcp-Session-Id and pin the client to whichever instance issued it, which meant teams needed session affinity, a shared session store, or a gateway smart enough to parse JSON bodies just to route calls correctly. Capability negotiation made it worse, since capabilities were exchanged once at connection time and could differ between sessions, which made caching across a shared intermediary a headache nobody wanted.
Six Specification Enhancement Proposals attack that problem from the same angle: make every request self-sufficient. Protocol version and client capabilities now ride along in _meta on each call, and a new server/discover method lets capabilities be queried independently instead of negotiated once upfront. The maintainers call this pay-as-you-go complexity — the core stays lean, and state only shows up where a feature actually needs it. For anything that genuinely requires memory, the answer is the explicit handle, the same pattern every web shopping cart has used for two decades: a tool mints something like a basket_id, hands it back in the result, and the client passes it along on the next call. Because it's visible to the model rather than buried in transport metadata, it can be composed across tools — though it also shows up in prompts and logs, so it needs to be tied to the authenticated principal and checked on every use, not treated as proof of anything.
The practical upshot for server operators is that a remote MCP server can finally behave like an ordinary stateless HTTP service: three replicas behind round-robin, no affinity rules, no protocol-level session store to babysit. Platform teams get a required Mcp-Method header, plus Mcp-Name for named operations, letting a gateway rate-limit or authorize by operation without ever opening the request body — provided transport validation rules are enforced, since a header that disagrees with the body underneath is otherwise trivially spoofable. Caching gets real teeth too: list and read results now carry ttlMs and cacheScope fields modeled on HTTP Cache-Control, and servers are expected to return tools in a deterministic order to improve prompt cache hit rates. None of that guarantees identical answers across replicas, though — statelessness buys routability, not determinism, and two servers running different versions can still disagree.
The extension model is where the long game shows. Official extensions live under io.modelcontextprotocol, third-party ones under a reversed domain the author controls, each with its own repository and release cadence — the same shape as a Kubernetes custom resource. Tasks is the case study: it shipped as an experimental core feature in the 2025-11-25 release, production use exposed problems, and it's being pulled out and rebuilt as an extension instead. Backing that up is a formal deprecation policy with Active, Deprecated, and Removed states, a minimum twelve-month deprecation window that can only shrink to ninety days for a documented security issue, and a public registry tracking what's on its way out.
None of this is free. Sampling is the sharpest trade-off in the whole release: a server relying on client-mediated Sampling never needed provider credentials or the model bill, but calling a provider API directly turns that same server into a credential holder, a billing party, and a data processor all at once. Logging loses its client-facing structured stream in favor of stderr and OpenTelemetry, which serves operators but not remote clients that relied on the old channel. The maintainers gave themselves a ten-week validation window and shipped beta SDKs for Python, TypeScript, Go, and C#, with clients probing server/discover first and falling back to initialize only for legacy servers — a negotiated wire-level break rather than a flag day for the whole ecosystem.
My take — AI-written commentary, not fact-checked reporting
MCP is basically admitting what web developers already knew: stateless HTTP with an explicit handle beats bespoke session machinery, every single time. Credit where it's due for pairing the break with an actual deprecation policy and a public registry instead of a changelog nobody reads. The real story, though, is Sampling — quietly shifting model calls and their bills onto server operators is the kind of tradeoff that looks like simplification until someone gets the invoice.
Read more about this at: The New Stack