MCP Becomes Stateless (Spec 2026-07-28): MCP Server Migration Checklist

#How Big of a Deal Is "Stateless"? (An Architect's View)

Before this release, a remote MCP server had to remember the client: the initialize handshake opened a session, and then the Mcp-Session-Id pinned the client to a specific server instance. Scaling horizontally required sticky routing based on session IDs or maintaining a shared data store (like Redis) so any instance could read the session state—exactly the kind of operational complexity that distributed systems engineers dread.

The 2026-07-28 spec removes this entirely. With no handshake and no session IDs at the protocol level, any request can be routed to any instance. Servers run on standard HTTP infrastructure, scaling via simple round-robin without sticky routing. For delivery managers and operators, this eliminates an entire infrastructure layer to maintain—but it means stateful servers assuming "an active session" must refactor how they manage state.

#What is Removed and What is Added

The paradigm shift: State does not disappear; it moves from being hidden in the transport layer to being explicit in the conversation. Instead of the server remembering the session, the server issues an explicit handle to the model, and the model carries it along.

#Checklist for Migrating MCP Servers to Stateless

This is the core roadmap—the exact sequence I would follow to migrate a live MCP server:

1. Upgrade the SDK. Wait for your language's SDK to release a version supporting the 2026-07-28 spec (Tier 1 SDKs are expected within the 10-week validation window). Avoid writing custom wrappers before the official SDK is ready.
2. Remove all Mcp-Session-Id assumptions. Audit where your server reads session IDs to look up state. This is the primary breaking point.
3. Replace sessions with explicit handles. Design your tool to "mint" and return a state handle (e.g., basket_id or browser_id). Subsequent tools should accept this handle as a regular parameter. The state is now held and passed back by the model.
4. Emit new headers. Send Mcp-Method and Mcp-Name (SEP-2243) so edge infrastructure can route requests without parsing the JSON-RPC request body.
5. Convert multi-step flows to input-required. Instead of keeping SSE connections open while waiting, return an InputRequiredResult containing inputRequests and requestState. The client will retry with inputResponses and the echoed requestState—which any server instance can now process.
6. Migrate Tasks to the new lifecycle. If using the experimental Tasks (from the 2025-11-25 spec), switch to the new standard: return a task handle in tools/call, and let the client manage execution via tasks/get, tasks/update, and tasks/cancel (SEP-2663—this is a breaking change).
7. Tighten authentication. Align with new security SEPs: validate iss parameters per RFC 9207 (SEP-2468), declare the OIDC application_type during Dynamic Client Registration (SEP-837), bind credentials to the issuer, and re-register upon issuer changes (SEP-2352).

To sum it up: Steps 2 and 3 are the heart of the migration (removing implicit sessions and using explicit handles); the rest covers routing headers, Tasks, and security. If your server is read-only or stateless, you will have almost zero migration effort.

#Extensions: MCP Apps and Tasks Become First-Class Citizens

This specification formalizes the Extensions Framework (SEP-2133): utilizing reverse-DNS identifiers, negotiating via the extensions capability map, living in separate ext-* repositories, and versioning independently from the core spec. Two official extensions stand out:

• MCP Apps (SEP-1865) — The server sends interactive HTML interfaces that the host renders in a sandboxed iframe. Tools declare UI templates beforehand, allowing hosts to prefetch, cache, and audit them for security. The UI communicates back using the underlying JSON-RPC channel, ensuring all actions share the same audit trail as standard tool calls. This is MCP stepping from "returning text/data" to "returning the entire user interface."
• Tasks (SEP-2663) — A standard for long-running executions without maintaining persistent connections: the server returns a task handle, and the client checks status or updates execution using tasks/get, tasks/update, and tasks/cancel.

#No Need to Panic: Official Deprecation Policy

This release introduces the official deprecation policy (SEP-2577): features move through Active → Deprecated → Removed, guaranteeing a minimum of 12 months between deprecation and removal. Three annotation-like mechanisms are deprecated in this version (but will continue to function normally):

If you have studied advanced MCP, these are the three mechanisms most frequently discussed. While the spec now recommends other paths, you have at least a full year to adapt—nothing will break overnight on July 28th.

#Conclusion

MCP is growing up: transitioning from a sessionful protocol loaded with hidden states into a stateless core running on standard HTTP, paired with a structured extensions framework. For MCP consumers, SDKs handle the transition. For MCP server authors, the message is clear: remove session dependencies, transition states to explicit handles, emit the new routing headers—and know that you have at least a year to address deprecated features.

To connect the dots: The foundations of MCP (client/server architecture, the three core capabilities, transport layers) are covered in Model Context Protocol. The stateless_http paradigm, Streamable HTTP, and session IDs—the very items changed in this spec—are discussed in Advanced Model Context Protocol. When building agents that interact with these servers, check out Claude Agent SDK vs Claude API vs Claude Code; and for agents operating directly on web pages, see WebMCP. The complete learning path is compiled at [/learn/claude?lang=en].

Nguyễn Phúc Nguyên Châu
Delivery Manager
14 years of delivery experience (Websites, Systems, AI Automation) for the Vietnam–Japan market