By The Model Context Protocol just shipped its biggest spec revision since launch. The 2026-07-28 release candidate, locked May 21, removes the initialize handshake, kills the Mcp-Session-Id header, and makes every MCP request self-contained. If you are running an MCP server — particularly behind a load balancer — this changes your deployment model. You have until July 28 to migrate. The ten-week window for Tier 1 SDK maintainers (TypeScript, Python) started the moment that RC locked.
What Actually Changed
Two SEPs do the heavy lifting. SEP-2575 removes the initialize/initialized handshake entirely. SEP-2567 kills Mcp-Session-Id. Together, they mean every request now carries its own protocol version, client identity, and capabilities inside a _meta object on the JSON-RPC envelope. A new server/discover method handles capability negotiation when clients need it up front.
The practical payoff: you can now run MCP behind a plain round-robin load balancer. No sticky sessions. No shared session stores. No deep-packet inspection at the gateway to figure out which instance owns a session. This was a genuine pain point — production teams reported cryptic timeouts when load balancers routed requests to the wrong instance. That problem goes away.
The Misconception Worth Addressing
A stateless protocol does not require stateless applications. Servers that need to track context across calls can still do it — they just do it the way every HTTP API has always done it: mint an explicit handle (session_id, cart_id, whatever makes sense for your domain), return it from a tool call, and let the model pass it back as an argument on subsequent calls. The spec documents this pattern explicitly. Your application logic does not change; your transport code does.
The Deprecations: Less Alarming Than They Sound
SEP-2577 deprecates three features: roots, sampling, and logging. The important word is deprecated, not removed. All three continue working in every spec version published within 12 months of July 28, 2026 — that runway takes you to mid-2027 at minimum. Migration paths exist for each:
- Roots — pass workspace paths as tool parameters or resource URIs
- Sampling — call the LLM API directly from your server code
- Logging — write to stderr or ship to OpenTelemetry
Do not rip these out when the final spec drops in July. Follow your SDK’s migration timeline. For the TypeScript SDK — 66 million npm downloads, 27,000+ dependent packages — that migration will be well-documented and gradual.
What Is New (and Additive)
The RC does not only remove things. The Extensions framework lands with this release: extensions get reverse-DNS IDs, live in dedicated ext-* repositories, and are negotiated through a standard capabilities map. Two extensions ship with the spec itself.
The Tasks extension reshapes long-running operations for the stateless model. A tools/call can now return a task handle instead of a result. The client drives the task lifecycle with tasks/get, tasks/update, and tasks/cancel. No persistent connection required. This is how you build agents that kick off multi-minute operations without holding a socket open.
MCP Apps (SEP-1865) lets servers ship sandboxed HTML interfaces that hosts render in an iframe. Tools declare their UI templates ahead of time so hosts can prefetch and security-review them before anything runs. Every UI-initiated action goes through the same JSON-RPC audit path as a direct tool call — server-authored UIs embedded in AI clients, no separate frontend deployment required.
Authorization Gets Real
Six SEPs in this RC align MCP’s authorization model with OAuth 2.1 and OpenID Connect. The most immediate action item is iss parameter validation per RFC 9207: future clients will reject authorization responses that omit iss, so if your authorization server does not supply it today, start there. Clients also now declare application_type during Dynamic Client Registration, which fixes the persistent problem where an auth server defaults a desktop or CLI client to “web” and rejects its localhost redirect URI.
For the first time, MCP has a formal deprecation policy: a minimum 12-month window between deprecation and removal, guaranteed by SEP-2596. Enterprise teams can finally plan migrations without guessing when the protocol will change under them.
What to Do This Week
The December 2025 transport future post previewed all of this; the RC is the delivery. For most teams, the action items are straightforward:
- Read the full RC announcement and identify which features you use that are changing
- Check your SDK release notes — Tier 1 SDKs have the 10-week window to ship support
- Audit your transport code for the
initializehandshake andMcp-Session-Idusage - Start supplying the
issparameter in authorization responses if you are not already - Leave roots, sampling, and logging alone until your SDK guides you through the migration
The stateless change is good engineering. Load balancer pain was real, and the architectural fix is the right call. The ten-week SDK window exists so that by July 28, your SDK does the heavy lifting — not you.
