The 2026-07-28 MCP Specification Release Candidate | Model Context Protocol BlogSkip to content<br>Table of ContentsA Stateless ProtocolBefore and after<br>The handshake and session are gone<br>Stateless protocol, stateful applications<br>Server-to-client requests, restructured<br>Routable, cacheable, traceable

Extensions Become First-ClassMCP Apps: server-rendered user interfaces<br>Tasks graduates to an extension

Authorization Hardening<br>Roots, Sampling, and Logging Are Deprecated<br>Full JSON Schema 2020-12 for Tools<br>How the Protocol Evolves From Here<br>Release Timeline and Validation<br>Looking Ahead

The release candidate for MCP 2026-07-28 is now available. It is the largest<br>revision of the protocol since launch and delivers on the<br>2026 roadmap:<br>a stateless core that scales on ordinary HTTP infrastructure<br>extensions including server-rendered UIs through MCP Apps and long-running work through the Tasks extension<br>authorization that aligns more closely with OAuth and OpenID Connect deployments<br>a formal deprecation policy so the protocol can evolve without breaking what you&rsquo;ve<br>built,<br>and many other changes.<br>The practical effect on a production deployment is immediate. A remote MCP<br>server that previously needed sticky sessions, a shared session store, and<br>deep packet inspection at the gateway can now run behind a plain round-robin<br>load balancer, route traffic on an Mcp-Method header, and let clients cache<br>tools/list responses for as long as the server&rsquo;s ttlMs permits.<br>The release candidate is available today and the final specification ships on<br>July 28, 2026 . This release contains breaking changes; see<br>Release Timeline and Validation for the<br>details.

A Stateless Protocol#<br>The headline change is that MCP is now stateless at the protocol layer. Six<br>Specification Enhancement Proposals<br>(SEPs) work together to get there, completing the plan we laid out in<br>The Future of MCP Transports in<br>December.

Before and after#<br>In 2025-11-25, calling a tool over<br>Streamable HTTP means establishing a session first:<br>POST /mcp HTTP/1.1<br>Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"initialize",<br>"params":{"protocolVersion":"2025-11-25","capabilities":{},<br>"clientInfo":{"name":"my-app","version":"1.0"}}}

The server responds with an Mcp-Session-Id that every subsequent request must<br>carry, pinning the client to whichever instance issued it:<br>POST /mcp HTTP/1.1<br>Mcp-Session-Id: 1868a90c-3a3f-4f5b<br>Content-Type: application/json

{"jsonrpc":"2.0","id":2,"method":"tools/call",<br>"params":{"name":"search","arguments":{"q":"otters"}}}

In 2026-07-28, the same call is a single self-contained request that any<br>server instance can handle:<br>POST /mcp HTTP/1.1<br>MCP-Protocol-Version: 2026-07-28<br>Mcp-Method: tools/call<br>Mcp-Name: search<br>Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",<br>"params":{"name":"search","arguments":{"q":"otters"},<br>"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

The handshake and session are gone#<br>The initialize/initialized handshake is removed<br>(SEP-2575).<br>The protocol version, client info, and client capabilities that used to be<br>exchanged once at connection time now travel in _meta on every request, and a<br>new server/discover method lets clients fetch server capabilities when they<br>need them up front.<br>The Mcp-Session-Id header and the protocol-level session that came with it are<br>also removed<br>(SEP-2567).<br>With both gone, any MCP request can land on any server instance, and the sticky<br>routing and shared session stores that horizontal deployments needed before are<br>no longer required at the protocol layer.<br>Stateless protocol, stateful applications#<br>Removing the protocol-level session does not mean your application has to be<br>stateless. Servers that need to carry state across calls can do what HTTP APIs<br>have always done: mint an explicit handle (a basket_id, a browser_id) from<br>a tool and have the model pass it back as an ordinary argument on later calls.

In practice, we&rsquo;ve found this pattern (the model threading an identifier from<br>one tool call to the next) to be more than just a workable substitute for<br>session state. It&rsquo;s often a more powerful one. The model can compose handles<br>across tools, reason about them, and hand them off between steps in ways that<br>externally managed session state, hidden in transport metadata, never really<br>allowed.<br>The protocol no longer manages that state for you, but it doesn&rsquo;t prevent you<br>from managing it yourself. The explicit-handle pattern simply makes the state<br>visible to the model rather than hidden away.<br>Server-to-client requests, restructured#<br>A stateless protocol still needs a way for servers to ask the client for<br>something mid-call, such as an elicitation prompt. Two SEPs rebuild that flow so<br>it works without a persistent connection.<br>Server-initiated requests may now only be issued while the server is actively<br>processing a client request<br>(SEP-2260).<br>Earlier spec versions recommended this; it&rsquo;s now...