MCP Just Deleted Its Own Session Layer — And That's the Point

The Model Context Protocol is about to do something most young standards refuse to do: admit that one of its foundational abstractions was wrong, and rip it out. The release candidate froze on May 21, per the MCP maintainers’ blog, and the final specification lands July 28. Sessions are gone. The initialization handshake is gone. Three core features are deprecated. If you built a remote MCP server around any of that machinery, you have work to do — and you should probably be thankful.

The Distributed Systems Tax MCP Was Quietly Charging

Here’s the fact the changelog buries: MCP was born as a desktop protocol. The canonical deployment was a local app talking to a local process over stdin/stdout, where a long-lived connection and a startup handshake cost essentially nothing. When servers moved to remote, horizontally scaled deployments, that model broke. Every MCP-Session-Id pinned a client to a specific instance, which forced operators into session affinity, shared session stores, or MCP-aware gateways that had to parse JSON request bodies just to route calls correctly.

Why it matters: teams shipping remote MCP servers were paying to solve a distributed-systems problem the protocol had invented for them. Capability negotiation added a second hidden tax — because capabilities were exchanged once at connect time, list results could vary per connection, making shared caching nearly impossible to reason about. If you’re a platform team running MCP behind a standard load balancer, this means the protocol was actively fighting your infrastructure choices. My take: any protocol that requires bespoke gateway logic to do stateless HTTP routing is leaking abstraction, and the maintainers deserve credit for calling it.

Why Every Request Now Stands On Its Own

Six Specification Enhancement Proposals converge on one goal: making every request self-contained. Protocol version and client capabilities now ride in _meta on each call. A new server/discover method makes server capabilities independently queryable, either up front or lazily. The maintainers call this “pay-as-you-go complexity” — the core stays lean, and statefulness only shows up where a feature genuinely needs it.

The obvious counter is that plenty of servers need to remember things. The answer is the explicit handle: a pattern every shopping cart on the web has used for two decades. A tool mints a basket_id, returns it in the result, and the model passes it back as an ordinary argument on the next call. What makes this more than a workaround is that the handle is visible to the model — it can be composed across tools and passed between workflow steps, which session state hidden in transport metadata never could be. If your team is building AI agents that chain multiple MCP tools together, this is actually a UX upgrade dressed up as a breaking change. My prediction: within a year, “handle-as-argument” will be treated as best practice in agent design docs the way JWT-in-header is treated in REST guides today.

What Server Authors and Platform Teams Actually Get

A remote MCP server can now run as a conventional stateless HTTP service — three replicas behind round-robin, no affinity configuration, no protocol session store to operate or recover. Rolling deploys stop invalidating sessions or stranding clients on removed instances. In-flight requests can still be interrupted (resumability is gone, so clients reissue under a new request ID), but the operational model becomes boring in the best possible way.

For platform teams, the required MCP-Method header — plus MCP-Name for named tool, resource, and prompt operations — means a gateway can rate-limit or authorize by operation without inspecting a request body. Per the draft transport validation rules, this only holds if the backend rejects headers that disagree with the body and a policy-enforcing intermediary refuses protocol versions that don’t guarantee that check. Skip that and a benign header can front a completely different call underneath. If you’re running MCP in a regulated environment — think fintech workloads where every tool call needs an audit trail — this is the first time the protocol lets your existing API gateway actually do its job. My take: the caching change (ttlMs and cacheScope modeled on HTTP Cache-Control, plus deterministic tool ordering for better prompt cache hit rates) is going to matter more to production cost curves than anyone is currently acknowledging.

Extensions Are the Real Long-Term Bet

The ecosystem argument is stronger than any individual feature. Extensions now get namespaced identifiers — official ones under io.modelcontextprotocol, third-party ones under a reversed domain the author owns — plus their own ext- repositories and release cadences. Anyone who has written a Kubernetes CRD will recognize the shape. Capabilities can ship and mature outside the core release train.

Tasks is the proof case. It shipped as an experimental core feature in 2025-11-25, real production use exposed design problems, and it’s been redesigned as an extension. Moving it out of core is itself a breaking spec change, but future iterations won’t be, because extensions evolve through capability flags or settings-level versioning. MCP Apps, already available as an extension, now sits inside a formally governed negotiation framework. If you’re a vendor building MCP-adjacent tooling — registries, gateways, marketplaces — this means you can innovate at your own tempo without waiting on the core spec cycle. My prediction: within eighteen months, the interesting fights in the MCP ecosystem will be about extension governance, not core protocol features.

The Deprecation Policy Is the Underrated Feature

The new feature lifecycle policy gives every feature an Active, Deprecated, and Removed state, with a minimum twelve-month window measured from the revision in which a feature first becomes Deprecated. That floor can only be shortened for an active security risk with a published advisory or documented exploitation, and even then ninety days is the hard minimum. A public registry lists what’s on the way out and by when. A Standards Track proposal can’t reach Final until a matching scenario lands in the conformance suite.

For developers, that sounds like housekeeping. For anyone who has to justify an MCP integration to a platform review board — legal, security, architecture — a written deprecation guarantee is worth more than any capability in the release. This is the single sentence that turns MCP from a “promising protocol” into something a Fortune 500 procurement team can actually sign off on. My take: this is the move that separates MCP from every other agent-tooling spec floating around, and it will show up in vendor RFPs by the end of the year.

What This Migration Actually Costs

None of this arrives free. Anyone who built against the experimental Tasks API migrates to the new lifecycle. Any server that issued its own requests to the client moves onto the Multi Round-Trip Requests pattern, where the server returns what it still needs and the client retries with the answers. That server must also authenticate any echoed requestState that can influence authorization or business logic — one-time workflows still need their own replay tracking.

Sampling is the sharpest case. A server using client-mediated Sampling needed no provider credentials and generally didn’t carry the model bill. Calling a provider API directly turns it into a credential holder, a billing party, and a separate processor of user data. Logging tells a similar story: stderr and OpenTelemetry answer operator observability, but they don’t give remote clients an equivalent of the structured log stream they used to receive. Application state doesn’t disappear either — handles, carts, task records, and idempotency keys still need somewhere to live. The protocol stopped managing state, which is not the same thing as the state going away. If you’re weighing whether to build an agent or an automation around MCP tools, this migration is a good forcing function to think carefully about who owns state at each layer.

FAQ

Q: What’s the biggest breaking change in the new MCP release? A: The removal of protocol-level sessions and the initialization handshake. Every request must now be self-contained, with protocol version and client capabilities traveling in _meta on each call. Servers can no longer rely on session affinity or a persistent MCP-Session-Id to pin clients to specific instances.

Q: When does the new MCP specification take effect? A: The release candidate was frozen on May 21, per the MCP maintainers, with final specification arrival scheduled for July 28. Beta SDKs are available for Python, TypeScript, Go, and C# during the ten-week validation window, and clients can probe with server/discover and fall back to initialize only for legacy-only servers.

Q: Do I have to rewrite my existing MCP server? A: If your server uses Sampling, experimental Tasks, or server-initiated requests, yes — you’ll need to migrate to the Multi Round-Trip Requests pattern or hold provider credentials directly. If your server was already mostly stateless and only used sessions incidentally, the migration is much lighter, and you’ll gain the ability to deploy behind a standard round-robin load balancer without affinity configuration.

Key Takeaways

• Audit your MCP servers now for session dependencies during the release-candidate window, before ratification forces the timeline
• Treat explicit handles (basket_id, task_id) as first-class design decisions and always bind them to authenticated principals — never treat them as proof of authorization
• Platform teams should require the MCP-Method and MCP-Name header validation in gateways to safely rate-limit and authorize without body inspection
• Vendors building on MCP should plan their roadmaps around the extensions ecosystem rather than lobbying for core spec changes
• The twelve-month deprecation guarantee is a stronger enterprise-adoption signal than any single feature in the release, and it will likely become table-stakes for competing agent protocols within a year