{"slug": "the-2026-07-28-specification", "title": "The 2026-07-28 Specification", "summary": "The Model Context Protocol (MCP) released specification version 2026-07-28, transforming from a bidirectional stateful protocol into a stateless request/response core for improved reliability and scalability. The update removes the initialize/initialized handshake and session headers, introduces Multi Round-Trip Requests (MRTR) to replace server-initiated streaming calls, and adds authorization hardening including RFC 9207 issuer validation and a shift to client metadata documents (CIMD). SDKs for TypeScript, Python, Go, and C# are updated to match, with TypeScript and Python each surpassing 1 billion total downloads.", "body_md": "Since our [last November release](/posts/2025-11-25-first-mcp-anniversary/) MCP continued to grow at an astonishing rate. Across our Tier 1 SDKs, we’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.\n\nToday, we’re officially pushing the release button on the next version of the MCP specification, `2026-07-28`\n\n, along with the SDKs that will allow you to start building clients and servers right away.\n\nThe 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.\n\nThere is, of course, more to what we’re introducing with this version:\n\n- 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.\n- Method and tool names travel in the\n`Mcp-Method`\n\nand`Mcp-Name`\n\nHTTP headers, so gateways can route and authorize on headers directly. - 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.\n- List responses carry cache hints and a deterministic order, so clients can cache tool catalogs and keep upstream prompt caches stable across reconnects.\n- Formally locking in on a proper extensions framework, with Tasks joining other extensions, such as MCP Apps and Enterprise Managed Authorization (EMA).\n- 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).\n- A formal deprecation policy with a twelve-month minimum window so you can plan upgrades instead of reacting to them.\n\nThe 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.\n\n## What changed[#](#what-changed)\n\n### No handshake or sessions[#](#no-handshake-or-sessions)\n\nWith the new spec version, we’ve officially retired the `initialize`\n\n/`initialized`\n\nexchange along with the `Mcp-Session-Id`\n\nheader (refer to [SEP-2575](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2575), [SEP-2567](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2567)). Each request now travels on its own, carrying its protocol version, client identity, and client capabilities in `_meta`\n\n. If a client wants to learn a server’s capabilities before doing anything else, there’s a new `server/discover`\n\nRemote 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.\n\n```\nPOST /mcp HTTP/1.1\nMCP-Protocol-Version: 2026-07-28\nMcp-Method: tools/call\nMcp-Name: search\n\n{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"tools/call\",\n \"params\":{\"name\":\"search\",\"arguments\":{\"q\":\"otters\"},\n \"_meta\":{\"io.modelcontextprotocol/clientInfo\":{\"name\":\"my-app\",\"version\":\"1.0\"}}}}\n```\n\nDropping the protocol-level session doesn’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.\n\n### Multi Round-Trip Requests (MRTR)[#](#multi-round-trip-requests-mrtr)\n\nMRTR replaces the server-initiated `elicitation/create`\n\n, `sampling/createMessage`\n\n, and `roots/list`\n\nrequests that previously required a held-open stream.\n\nSometimes a tool needs something from the user mid-call, such as a confirmation or a missing parameter. MRTR ([SEP-2322](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2322)) enables this scenario over a stateless protocol: the server returns `resultType: \"input_required\"`\n\nalong with the requests it needs answered, and the client retries the original call with the answers attached in `inputResponses`\n\n.\n\n### Header-based routing[#](#header-based-routing)\n\nStreamable HTTP requests now must include `Mcp-Method`\n\nand `Mcp-Name`\n\n([SEP-2243](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2243)). Your gateway, rate limiter, or WAF can route and meter on those headers instead of parsing JSON bodies.\n\n### List results are cacheable[#](#list-results-are-cacheable)\n\nResponses from `tools/list`\n\n, `prompts/list`\n\n, `resources/list`\n\n, and `resources/read`\n\nnow carry `ttlMs`\n\nand `cacheScope`\n\n([SEP-2549](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2549)). This allows clients to determine the best caching strategy for responses and reduce unnecessary re-fetching.\n\n### Authorization[#](#authorization)\n\nFrom our discussions with implementers for the past year, authorization is where implementers spend most of their integration time. With this spec revision, we continued evolving the MCP auth and security posture.\n\n- Authorization servers should return the\n`iss`\n\nparameter per[RFC 9207](https://www.rfc-editor.org/rfc/rfc9207), and clients must validate it before redeeming a code ([SEP-2468](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2468)). This closes an authorization-server mix-up hole. - Clients set\n`application_type`\n\nduring Dynamic Client Registration (DCR) so authorization servers stop rejecting`localhost`\n\nredirects for desktop and CLI apps ([SEP-837](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/837)). If you’ve ever wondered why your CLI client’s OAuth flow got a`redirect_uri`\n\nerror, this is likely why. And while we’re moving to Client ID Metadata Documents (CIMD) as the standard, this is a hardening measure making the protocol comply with OAuth spec requirements. - Client credentials are bound to the issuer that minted them. No reuse across authorization servers (\n[SEP-2352](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2352)). - Dynamic Client Registration itself is now formally deprecated in favor of CIMD. DCR continues to work for backward compatibility, but will be removed in a future version of the MCP spec.\n\n### Tasks[#](#tasks)\n\nTasks move out of the experimental core and into the `io.modelcontextprotocol/tasks`\n\nextension, with a poll-based `tasks/get`\n\nand a new `tasks/update`\n\n([SEP-2663](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2663)). Change notifications move from the old HTTP GET endpoint to a single `subscriptions/listen`\n\nstream that clients opt into per notification type.\n\n### Deprecations[#](#deprecations)\n\nRoots, Sampling, and Logging are deprecated ([SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577)). They still work, and they’ll keep working for at least twelve months. New implementations shouldn’t adopt them. The legacy HTTP+SSE transport is also considered to be officially deprecated, with a year-long offramp.\n\n## SDKs[#](#sdks)\n\nAll four Tier 1 SDKs speak `2026-07-28`\n\nas of today:\n\nBeyond the Tier 1 set, the [Rust SDK](https://github.com/modelcontextprotocol/rust-sdk) supports the new spec in beta.\n\nThe SDKs implement APIs that allow you to build both servers and clients with the new spec version. As we mentioned in the [SDK beta blog post](/posts/sdk-betas-2026-07-28/), there will be some migration cost, especially for developers that did depend on session identifiers; however, we incorporated early testing feedback that makes this process much easier.\n\n## Ecosystem support[#](#ecosystem-support)\n\nAs with any large release, the work that we’re doing with MCP would not be possible without contributions from folks across the ecosystem. We’re also especially grateful to a number of contributors and partners who helped us test and validate the spec before it became generally available.\n\n## Getting started[#](#getting-started)\n\nWe’re excited to have developers build on the new spec. To get started, refer to the following resources:\n\n## Thank you[#](#thank-you)\n\nThis release would not be possible without a massive community of contributors and industry partners. We’d like to acknowledge the dozens of key contributors across specification, documentation, SDKs, working and interest groups, as well as hundreds of independent worldwide communities who rallied support and excitement for MCP. We’re looking forward to continuing evolving the protocol as it grows!", "url": "https://wpnews.pro/news/the-2026-07-28-specification", "canonical_source": "https://blog.modelcontextprotocol.io/posts/2026-07-28/", "published_at": "2026-07-28 09:00:00+00:00", "updated_at": "2026-07-28 17:29:28.159629+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "developer-tools", "ai-infrastructure"], "entities": ["Model Context Protocol", "TypeScript", "Python", "Go", "C#", "RFC 9207", "SEP-2575", "SEP-2567"], "alternates": {"html": "https://wpnews.pro/news/the-2026-07-28-specification", "markdown": "https://wpnews.pro/news/the-2026-07-28-specification.md", "text": "https://wpnews.pro/news/the-2026-07-28-specification.txt", "jsonld": "https://wpnews.pro/news/the-2026-07-28-specification.jsonld"}}