The 2026-07-28 Specification | Model Context Protocol BlogSkip to content<br>Table of ContentsWhat changedNo handshake or sessions<br>Multi Round-Trip Requests (MRTR)<br>Header-based routing<br>List results are cacheable<br>Authorization<br>Tasks<br>Deprecations

SDKs<br>Ecosystem support<br>Getting started<br>Thank you

Since our last November release MCP continued to grow at an astonishing rate. Across our Tier 1 SDKs, we&rsquo;re seeing close to half-a-billion downloads a month, with both TypeScript and Python SDKs crossing the 1 billion total downloads threshold. In just a few months, the protocol continued to grow as the data and interactivity substrate for agentic workflows.<br>Today, we&rsquo;re officially pushing the release button on the next version of the MCP specification, 2026-07-28, along with the SDKs that will allow you to start building clients and servers right away.<br>The highlight of this release is a stateless protocol core - MCP is transforming from a bidirectional stateful protocol into a request/response stateless protocol. It was one of the most highly-requested features from developers who were eager to get better reliability and scalability for their MCP servers.

A short demo of the stateless protocol core in action.There is, of course, more to what we&rsquo;re introducing with this version:<br>Every request is self-describing, with an optional discovery call for clients that want capabilities up front, so any request can land on any instance behind a plain round-robin load balancer.<br>Method and tool names travel in the Mcp-Method and Mcp-Name HTTP headers, so gateways can route and authorize on headers directly.<br>Server-to-client requests for things like sampling and elicitation are being redesigned to use Multi Round-Trip Requests (MRTR), removing the need for constantly open bidirectional streams.<br>List responses carry cache hints and a deterministic order, so clients can cache tool catalogs and keep upstream prompt caches stable across reconnects.<br>Formally locking in on a proper extensions framework, with Tasks joining other extensions, such as MCP Apps and Enterprise Managed Authorization (EMA).<br>A set of authorization hardening changes including RFC 9207 issuer validation and a formal shift away from Dynamic Client Registration (DCR) toward client metadata documents (CIMD).<br>A formal deprecation policy with a twelve-month minimum window so you can plan upgrades instead of reacting to them.<br>The TypeScript, Python, Go, and C# SDKs are updated to match, with detailed migration notes for the breaking bits - and you can get started with the new spec right away.<br>What changed#<br>No handshake or sessions#<br>With the new spec version, we&rsquo;ve officially retired the initialize/initialized exchange along with the Mcp-Session-Id header (refer to SEP-2575, SEP-2567). Each request now travels on its own, carrying its protocol version, client identity, and client capabilities in _meta. If a client wants to learn a server&rsquo;s capabilities before doing anything else, there&rsquo;s a new server/discover Remote Procedure Call (RPC) for that; however, it is not required. Any request can now land on any server instance behind a plain round-robin load balancer without needing shared storage.<br>POST /mcp HTTP/1.1<br>MCP-Protocol-Version: 2026-07-28<br>Mcp-Method: tools/call<br>Mcp-Name: search

{"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"}}}}

Dropping the protocol-level session doesn&rsquo;t force your application to be stateless. If your server needs to carry state across calls, mint an explicit handle from a tool and have the model pass it back as an argument. We found this works better than session state hidden in the transport - the model can see the handle and thread it between tools.<br>Multi Round-Trip Requests (MRTR)#<br>MRTR replaces the server-initiated elicitation/create, sampling/createMessage, and roots/list requests that previously required a held-open stream.<br>Sometimes a tool needs something from the user mid-call, such as a confirmation or a missing parameter. MRTR (SEP-2322) enables this scenario over a stateless protocol: the server returns resultType: "input_required" along with the requests it needs answered, and the client retries the original call with the answers attached in inputResponses.<br>Header-based routing#<br>Streamable HTTP requests now must include Mcp-Method and Mcp-Name (SEP-2243). Your gateway, rate limiter, or WAF can route and meter on those headers instead of parsing JSON bodies.<br>List results are cacheable#<br>Responses from tools/list, prompts/list, resources/list, and resources/read now carry ttlMs and cacheScope (SEP-2549). This allows clients to determine the best caching strategy for responses and reduce unnecessary re-fetching.<br>Authorization#<br>From our discussions with implementers for the past year, authorization is where implementers spend most of their integration time. With this...