UnsplashThe new MCP spec: what changes if you already run a server
The 2026-07-28 release makes the protocol stateless, moves routing into HTTP headers, and starts a twelve-month clock on three features you may be using.
MCP's 2026-07-28 specification is the largest change since remote servers arrived. The short version: the protocol core is stateless, a remote MCP server is now an ordinary HTTP workload, and three features you may currently depend on are deprecated with a twelve-month support window. If you maintain a server, this is a migration rather than an upgrade.
Sessions are gone
The initialize and initialized exchange is gone, and so is the Mcp-Session-Id header. Protocol-level sessions have been removed entirely. Every request is self-describing, with an optional discovery call for clients that want to know capabilities up front.
The practical consequence is the whole reason for the change. A stateful, bidirectional protocol needs sticky routing, connection affinity and somewhere to keep session state, which is why hosting a remote MCP server was harder than hosting an API. Stateless removes all of that. You can put a server behind an ordinary load balancer and scale it horizontally like anything else you already run.
If your server keeps per-session state in memory between calls, that assumption no longer holds, and this is the part of the migration that is actual work rather than a config change.
Routing moved into headers
Method and tool names now travel in Mcp-Method and Mcp-Name HTTP headers. A gateway can route a request without parsing the JSON body, which means rate limiting, authorisation and traffic splitting can happen at the edge with the infrastructure you already have.
Two more additions matter for anything long-running. Multi Round-Trip Requests replace server-initiated requests that needed an open stream, so a server can still ask the user to confirm something mid-call over a stateless connection. And list results for tools, prompts and resources are now cacheable, carrying ttlMs and cacheScope so clients can stop re-fetching a catalog that rarely changes.
The deprecations, and the clock
Twelve months, starting now
Roots, Sampling and Logging are deprecated with a minimum twelve-month support window. The legacy HTTP+SSE transport is deprecated with a year-long transition. Nothing breaks today. Everything on that list breaks eventually, and "eventually" is the kind of deadline that arrives without warning.
Sampling is the one to check first. It was the mechanism for a server asking the client's model to generate something, and servers that used it are architecturally coupled to a feature with an expiry date. Roots and Logging are more mechanical to replace.
Authorization got stricter
- RFC 9207 issuer validation is now required before a code is redeemed, closing a class of mix-up attack
- Client credentials are bound to the issuing authorization server, so a credential from one cannot be replayed at another
- Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents
- An `application_type` parameter during registration stops localhost redirects being rejected outright, which was a real friction point for local clients
If you run an authenticated remote server, this section is not optional reading. The DCR deprecation in particular changes how clients get registered with you.
Extensions are now a real thing
Tasks has moved out of the experimental core and into a formal extension, io.modelcontextprotocol/tasks, with poll-based tasks/get and a new tasks/update. It joins MCP Apps, which lets a server render its own UI, and Enterprise Managed Authorization in a proper extensions framework.
This is a healthier shape than the alternative. The core stays small enough to implement completely, and the ambitious pieces evolve on their own schedule without every client having to support them to claim conformance.
What to actually do
- Grep your server for
initialize, session identifiers, and any state held between calls. That is the migration - Check whether you use Sampling, Roots or Logging. If yes, plan the replacement now rather than at month eleven
- If you are on the legacy HTTP+SSE transport, move to the current one while it is a choice
- Update your SDK. TypeScript, Python, Go and C# all support the new spec, Rust is in beta
- If you run behind a gateway, the header routing is free capability you can now use
If you only consume MCP servers
Almost none of this is your problem. Keep your client updated and the transport changes underneath you. The one thing worth checking is whether any server you depend on is actively maintained, because a server that misses this migration will eventually stop working and an abandoned one will not be fixed.
For scale, the Tier 1 SDKs now see close to half a billion downloads a month, and TypeScript and Python have each crossed a billion total. That is the size of the installed base this migration is moving, which is also why the deprecation windows are a year rather than a quarter.
Kapyn keeps a curated MCP directory with live registry status, and a config path reference for every major client. If you are new to the protocol, start with what MCP is.
Find these on the Radar
Every tool here lives on Kapyn Radar. Save the ones that fit into a Loadout and find them again.
