If you built an MCP server before this summer, you built it on a stateful protocol that no longer exists in the same form. The 2026-07-28 specification retired the handshake, the session header and the held-open streams, and it did so deliberately.

The good news is that this is one of the better-managed breaking changes in recent memory. Here is how to work through it.

What Actually Broke

• The initialize and initialized exchange is gone, along with the Mcp-Session-Id header. Each request now carries its own protocol version, client identity and capabilities.
• Server-initiated requests such as elicitation and sampling no longer use a held-open stream. They use Multi Round-Trip Requests, where the server returns input_required and the client retries with answers attached.
• Roots, Sampling and Logging are deprecated, as is the legacy HTTP and SSE transport. All still work, with at least a twelve-month window.
• Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents, with removal reported as slated after summer 2027.

The Clock You Are Working Against

The specification introduced a formal feature lifecycle. Features are Active, Deprecated or Removed, and a deprecated feature must remain available for at least twelve months before it can be removed.

That is the most useful sentence in the release for anyone running production systems. You are not firefighting, you are planning. Put a date in the calendar rather than a task in a backlog.

The Migration Plan

1. Audit your dependence on sessions. If your server never used session identifiers, your migration is mostly an SDK upgrade. Find out first, because many servers are simpler than their authors remember.
2. Upgrade the SDK on a branch. All four Tier 1 SDKs speak the new spec, with migration notes for the breaking parts. Rust is available in beta.
3. Stand up a strict stateless route beside the existing one. Do not replace, add. Both can serve from the same endpoint.
4. Move features across one at a time. Tools first, since they are usually stateless already. Elicitation last, because that is the real work.
5. Let active sessions drain. Monitor usage of the legacy path until it approaches zero.
6. Delete the legacy route inside the deprecation window, deliberately rather than under pressure.

What You Get For the Trouble

One framework maintainer reported cutting package size by roughly 83% and improving speed by around 25% on the new client and server split, which is an unusually pleasant outcome for a breaking change.

If You Are a Client Rather Than a Server

Your work is usually much smaller. Upgrading the SDK handles most of it, and endpoints commonly accept both new stateless requests and older Streamable HTTP clients, so most clients reconnect without configuration changes.

Test elicitation flows specifically, because that is where the interaction model genuinely changed.

Conclusion

Audit your session dependence first, because it decides whether this is a day or a fortnight. Run the stateless route alongside the old one, migrate tools before elicitation, and drain rather than cut over. Use the twelve-month window as a plan rather than a cushion. The payoff is a server that runs as an ordinary HTTP workload, and that is worth the sprint.

Frequently Asked Questions

Can we skip this and stay on the old spec?

For a while. But clients are moving, SDK effort is going to the new spec, and the legacy transport is deprecated. Delay is a cost you pay later with less help available.

How long does a typical migration take?

Days for a stateless tools-only server. Weeks for one relying on sessions and server-initiated requests. The audit in step one tells you which you are.

What about desktop servers using stdio?

Much less affected, since stdio was always a local subprocess model. Check your SDK version and your use of deprecated primitives, then move on.