MCP Goes Stateless on July 28. Delete Your Session Store.

Eighteen days. That's how long you have.

The 2026-07-28 MCP specification release candidate removes the session concept from the protocol layer entirely. The initialize / initialized handshake is gone. The Mcp-Session-Id header is gone. Protocol version, client identity, and capabilities now travel in a _meta object attached to every request.

The consequence is the whole point: any server instance can serve any request. A remote MCP server now runs behind a plain round-robin load balancer. No sticky sessions. No shared Redis session store. No connection affinity. If you built session state into your remote MCP server, you're not migrating it. You're deleting it.

Hosts route on a new Mcp-Method header, which means proxies and gateways can make routing decisions without parsing the JSON-RPC body. Clients may cache tools/list responses for as long as the server's ttlMs permits, so your tool list becomes a cacheable resource with an explicit expiry rather than something re-fetched on every connection.

Three original-spec features get deprecated in the same RC, under the protocol's first formal deprecation policy: Roots, Sampling, and Logging. If you have a server calling Sampling, that's an audit item this week, not next month. The RC also introduces an extensions framework where new capabilities ship opt-in and stabilize outside the spec before moving into it, which changes the upgrade calculus. You can adopt an extension without waiting for a spec revision, and you get a defined window before something you depend on disappears.

Two extensions matter. MCP Apps standardizes the ad-hoc embedded-UI experiments into server-rendered HTML in a sandboxed iframe, and the design constraint is worth stealing wholesale: tools declare their UI templates in advance rather than streaming markup at call time, so the host can prefetch, cache, and security-review the template before anything runs. Actions taken inside the rendered UI route back through the same JSON-RPC base protocol, inheriting the identical consent and audit path as a direct tool call. Tasks was redesigned for a sessionless world: a server answers tools/call with a task handle, and the client drives the lifecycle through tasks/get, tasks/update, and . The server decides which calls become tasks, so a tool can transparently become long-running without a client-side contract change.