The release candidate for the next Model Context Protocol spec is out, and the final version ships on 28 July 2026. It's the largest revision since MCP launched: a stateless protocol core, an Extensions framework, hardened authorization, and — for the first time — a formal deprecation policy. If you build or operate MCP servers, this is the one to read ahead of the deadline rather than after something breaks.
The headline: MCP goes stateless
The defining change is that the protocol is now stateless at its core. A remote server that previously needed sticky sessions, a shared session store and deep packet inspection at the gateway can now run behind a plain round-robin load balancer. Two practical mechanics make that work. Streamable HTTP requests must carry Mcp-Method and Mcp-Name headers (SEP-2243) so a gateway can route on the operation without parsing the JSON body. And list and read results can now carry ttlMs and cacheScope fields (SEP-2549), modelled on HTTP Cache-Control, so clients cache tools/list instead of re-polling. The upshot: MCP servers start to behave like ordinary stateless web services, which is exactly what makes them cheap to scale. The full path is covered in the stateless server migration guide.
Extensions: a framework, not just features
Tasks, MCP Apps and elicitation no longer arrive as one-off bolt-ons. They're now part of an Extensions framework: new capabilities ship as opt-in extensions, prove themselves in the wild, and only graduate into the core spec if they earn it. That keeps the base protocol small while letting the ecosystem move fast. If you've already adopted the Tasks extension for async tools, elicitation for human-in-the-loop or MCP Apps, you're effectively running the new model already — the spec is just formalising how those pieces are versioned and stabilised.
Authorization that enterprises can actually deploy
The auth story matured the most. MCP servers are now formally OAuth 2.1 resource servers. They must implement Protected Resource Metadata (RFC 9728) so clients can discover the right authorization server automatically, and clients must send Resource Indicators (RFC 8707) so a token is bound to one specific server — closing the door on a malicious server stealing a token meant for another. Token passthrough stays explicitly forbidden — the fix for the classic confused-deputy problem. See token passthrough prevention and enterprise managed connectors.
A deprecation policy you can plan around
For the first time, every feature gets an Active → Deprecated → Removed lifecycle with at least twelve months between deprecation and the earliest removal. That sounds bureaucratic; it's actually the thing that lets you build on MCP without fearing a silent rug-out. The HTTP+SSE transport is the first big casualty of the old, informal approach — read SSE deprecated, migrate to Streamable HTTP — and the new feature lifecycle and deprecation policy means future retirements come with a real runway.
What to do before 28 July
The ten-week candidate window is for SDK and client maintainers to validate, not a reason to scramble. If you run a server: confirm your SDK is on a current major, add the new transport headers, and decide your ttlMs values. If you're a user with remote connectors, the changes are mostly invisible — except where an old /sse endpoint is being switched off. New to all this? Start with what is MCP or grab a ready loadout.