The Model Context Protocol is about to change in a fundamental way. The release candidate for the 2026-07-28 specification is now live, and it marks the largest architectural shift since MCP was open-sourced. The headline: MCP is going stateless — and everything about how you build, deploy, and scale AI tool servers follows from that decision.
The final spec ships July 28. Here is what changed, what is deprecated, and how to migrate.
The Big Change: MCP Goes Stateless
Previous versions of MCP required a session handshake. Every client-server relationship began with an initialize / initialized exchange that established a session, after which the Mcp-Session-Id header pinned all subsequent requests to a specific server instance. That design was fine for single-node deployments, but in distributed environments it created real friction: sticky routing at the load balancer, shared session stores between instances, and workarounds that added operational overhead without adding value.
The 2026-07-28 release candidate removes all of it. The initialize handshake is gone. The Mcp-Session-Id header no longer exists. Any MCP request can land on any server instance, which means a standard round-robin load balancer is now enough — no coordination layer required.
Client metadata that previously lived in the session handshake now travels in _meta on every request. Server capabilities are retrieved on-demand via a new server/discover method. Application-level state still works exactly as before — you thread explicit handle identifiers through tool calls rather than relying on hidden transport state.
Infrastructure impact
For teams running MCP servers at scale, this is the change you have been waiting for:
- No sticky routing at the load balancer layer
- No shared session stores between instances
- Horizontal scaling with zero protocol-level coordination
- Simpler disaster recovery — server instances are fully interchangeable
MCP Apps: Interactive UIs in Your Tools
MCP Apps are a new first-class extension that lets servers deliver interactive interfaces inside the client. Instead of plain text or structured JSON, a tool can return a sandboxed iframe containing a full server-rendered HTML UI.
Tools declare UI templates ahead of time for prefetching and security review. Once rendered, UI interactions flow through the same JSON-RPC protocol as standard tool calls — same audit trail, same consent mechanisms.
The use cases this unlocks include: approval workflows with rich form UIs, data visualization dashboards embedded in the agent response, and multi-step configuration flows that feel native to the client. All of this happens within the MCP layer, without any custom side channels.
Tasks Extension: Long-Running Work Made Official
Tasks were previously an experimental feature in the core spec. The 2026-07-28 RC promotes them to an official extension with a redesigned lifecycle suited to the stateless model.
The new flow:
- A
tools/callresponse returns a task handle instead of an immediate result - Clients drive execution via
tasks/get,tasks/update, andtasks/cancel tasks/listis removed — without sessions, listing all in-flight tasks has no safe definition
If you have an existing Tasks implementation built on the experimental 2025-11-25 API, migration is required. The server-directed lifecycle is a meaningful redesign of the previous model.
Multi Round-Trip Requests
A new InputRequiredResult pattern — called Multi Round-Trip Requests (MRTR) — lets tools pause mid-execution and request additional input from the user. The client surfaces the prompt, collects input, and resumes execution with the response.
This matters for tools that need clarification before taking an irreversible action, or for workflows where the correct parameters depend on intermediate results that only emerge at runtime.
Authorization Hardening
Six enhancement proposals bring MCP's authorization closer to standard OAuth 2.0 and OpenID Connect practices:
- Clients must validate the
issparameter per RFC 9207 to prevent mix-up attacks - Clients declare
application_typeduring OpenID Connect registration - Credentials are bound to the issuing authorization server
- Refresh token request patterns are now documented
- Scope accumulation and discovery mechanisms are clarified
These are not breaking changes. They formalize practices that secure MCP deployments were already following.
What Is Deprecated
Three features receive formal deprecation under a new twelve-month lifecycle policy. They remain functional — this is an annotation, not a removal:
| Deprecated Feature | Recommended Replacement |
|---|---|
| Roots | Tool parameters, resource URIs, or server configuration |
| Sampling | Direct LLM provider API integration |
| Logging | stderr for stdio transport; OpenTelemetry for structured observability |
The formal deprecation policy guarantees at least twelve months between deprecation annotation and any removal consideration. No more surprise breaking changes in the next revision cycle.
Gateway Routing Without Body Parsing
Two new transport headers — Mcp-Method and Mcp-Name — allow API gateways to route requests by method and tool name without parsing the JSON-RPC request body. This is a practical addition for edge deployments and security architectures that need to route specific tool calls to different backends.
Migration Checklist
Two changes require action before the final spec:
Error code: Missing resources previously returned the custom code -32002. The spec now mandates the standard JSON-RPC code -32602. Update any client-side error-matching logic.
Session removal: If your client or server sets or reads Mcp-Session-Id, remove that code. If your server pushes capabilities during initialize, switch to responding to server/discover instead.
SDK Betas Are Available Now
Beta releases for all four Tier 1 SDKs are live:
# Python
pip install "mcp[cli]==2.0.0b1"
# TypeScript
npm install @modelcontextprotocol/server@beta
# Go
go get github.com/modelcontextprotocol/go-sdk@v1.7.0-pre.1
# C#
dotnet add package ModelContextProtocol --prereleaseTypeScript users get an automated codemod for the v1-to-v2 migration:
npx @modelcontextprotocol/codemod@beta v1-to-v2 .Both Python and TypeScript include migration guides. Backward compatibility is maintained — v2 servers respond to legacy protocol requests, so you can migrate on your own schedule.
Timeline
- Release candidate: Live now
- Final specification: July 28, 2026
- Tier 1 SDK stable releases: Within ten weeks of the final spec
What to Do Next
The stateless shift is the right architectural call for AI tooling at scale, and the migration path is well-supported by the SDK betas. Read the official release candidate announcement and the SDK beta post to understand your specific scope.
July 28 is close. The tooling is ready. Start the migration now.