The Model Context Protocol's biggest revision since launch finalizes tomorrow, 2026-07-28, and the headline is subtraction. It deletes the session, the initialize handshake, and the Mcp-Session-Id header. If you run an MCP server, the change you feel first isn't a new feature — it's that your deploy gets simpler.
The one-line answer: MCP 2026-07-28 makes the protocol stateless. SEP-2567 removes theMcp-Session-Idheader and SEP-2575 removes theinitialize/initializedhandshake — protocol version, client info, and capabilities now travel in_metaon every request. So any request can hit any instance behind a plain round-robin load balancer, with no sticky routing and no shared session store. Nothing you run today breaks tomorrow — deprecated features keep working for ~12 months, and new clients fall back to the old handshake against old servers.
We covered what the spec changes and why it got smaller. This is the other half: the checklist. Here is what a server author actually touches, in the order the work bites.
1. Make the deploy stateless (the easy win)#
This is the change most people can adopt with almost no code and immediate payoff.
- Stop reading and emitting
Mcp-Session-Id. Delete any routing, cache key, or lookup that depends on it. - Remove sticky-session affinity at the load balancer. Put your instances behind plain round-robin.
- Drop the shared session store you kept only to survive a client reconnecting to a different instance. With no protocol session, there's nothing to pin.
The payoff is real: horizontal scaling stops being a distributed-state problem. A cold instance is as good as a warm one because there's no session to warm.
2. Move the handshake into _meta#
The initialize/initialized round-trip is gone. Read the protocol version, client info, and client capabilities from _meta on each incoming request instead of from a one-time handshake you cached.
- If you advertised capabilities during
initialize, expose them through the newserver/discovermethod so clients can fetch them up front when they need to. - Interop is handled for you: a 2026-07-28 client falls back to
initializewhen it detects a 2025-11-25-or-earlier server. You don't have to ship both paths in a panic — you have the deprecation window.
3. Migrate long-running work to Tasks (the real rework)#
This is where 2025-11-25 code needs actual surgery. Live SSE streams that held a connection open for a long-running tool don't fit a world where any request can land anywhere. The replacement is the poll-based Tasks extension (SEP-2663):
tools/callcan return a task handle instead of a final result.- The client drives it by polling —
tasks/getto read state,tasks/updateto supply an input the task asked for,tasks/cancelto stop it. - The lifecycle is a small state machine:
working → input_required → completed / failed / cancelled. Oninput_required,tasks/getreturns the inputs it needs; you fulfill them withtasks/update, and it returns toworking. tasks/listwas removed — deliberately. Without a session, enumerating "all my tasks" can't be scoped safely across requests.
The consequence for your architecture: persist task state in a shared, durable store, because a poll for a given task id can hit any instance. The task's identity moves into your storage layer, where it belongs, instead of living in a connection.
4. Delete Sampling and Roots#
Two client-facing capabilities are deprecated, and both hand responsibility back to the host:
- Sampling (the server asking the host's LLM to generate) → call an LLM provider's API yourself. The server owns its own model access now.
- Roots (the client advertising filesystem scope) → tool parameters, resource URIs, or server configuration. The filesystem boundary is the host's to set, not a protocol negotiation.
- Logging → stderr on stdio transport, or OpenTelemetry over HTTP.
What you get for free (and can ignore for now)#
The same release ships MCP Apps (SEP-1865) — a server can now ship an interactive HTML UI as a ui:// resource, rendered by the host in a sandboxed iframe, with every UI action routed back over the same audited JSON-RPC path as a normal tool call. It's additive. Adopt it when you want a richer surface; nothing forces it.
The honest timeline#
Finalization is tomorrow, but "final" is not "flag day." The deprecation policy keeps removed features working through every spec version published within a year of the one that deprecated them — a ~12-month floor — and the handshake fallback means new and old peers keep talking. So treat this as a migration you schedule, not a rewrite you rush. Do step 1 this week for the free scaling win. Book step 3 — the Tasks rework — as a real project, because that's the one that changes how your server thinks about time.
