The GenAI Field Guide · Trending
The largest revision of the Model Context Protocol so far: no handshake, no sessions, every request self-describing, so an MCP server can run as an ordinary stateless HTTP service.
The 2026-07-28 revision of MCP removes the initialize handshake and the Mcp-Session-Id header, so any server instance can answer any request. Mid-call questions to the user now work by returning an input_required result and letting the client retry, routing headers let gateways see the method and tool without parsing JSON, and client registration moves from Dynamic Client Registration to Client ID Metadata Documents. If you run or build remote MCP servers, this changes how you deploy, scale, authorize and test them; it contains breaking changes, and the official SDKs bridge old and new clients from one endpoint.
MCP is the open protocol that lets an AI application (the client) discover and call tools, read resources and fetch prompts from a separate program (the server). Until this revision a connection began with an initialize and initialized exchange, and remote servers over Streamable HTTP kept a session identified by an Mcp-Session-Id header. That made a remote MCP server a stateful service: sticky load balancing or a shared session store, and long-lived streams the server used to send requests back to the client.
The 2026-07-28 specification, published on 28 July 2026 after a release candidate locked on 21 May 2026, removes that state from the protocol. The maintainers describe it as the largest revision since launch, and the release candidate post says plainly that it contains breaking changes. Alongside statelessness it adds header-based routing, cacheable list results, a new pattern for mid-call input, a set of authorization hardening changes, a formal extensions framework (with Tasks, MCP Apps and Enterprise Managed Authorization as the first extensions), and a deprecation policy with a minimum twelve-month window.
Under the marketing, the practical meaning is narrow and useful: a remote MCP server can now be deployed like any other stateless HTTP API. Google's write-up describes plain round-robin load balancing and serverless hosting on Cloud Run and Cloud Functions with no session store; Cloudflare says a server can run in a single Worker with no stateful infrastructure. State your server genuinely needs across calls does not disappear; the specification says to pass it as explicit, server-minted handles in ordinary tool arguments.
Every request is self-describing. Protocol version, client capabilities and (recommended) client identity travel in the request's _meta under keys such as io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientCapabilities and io.modelcontextprotocol/clientInfo, and servers should identify themselves in each result's _meta. A new server/discover method, which servers must implement, lets a client learn supported versions, capabilities and identity up front, or probe a stdio server for backward compatibility. A version mismatch returns an UnsupportedProtocolVersion error, renumbered to -32022 in the final text. ping, logging/setLevel and the roots change notification are removed; log level is now set per request in _meta.
Mid-call input uses Multi Round-Trip Requests (MRTR) instead of server-initiated requests over an open stream. When a tools/call, resources/read or prompts/get needs something from the user or client, the server returns a result with resultType input_required, an inputRequests map (elicitation, sampling or roots requests) and an optional opaque requestState. The client gathers the answers and retries the original request with a new JSON-RPC id, inputResponses and the exact requestState. The spec says servers must treat requestState as attacker-controlled, protect its integrity (for example with HMAC or AEAD) when it affects authorization or business logic, and should bind it to the principal, the originating request and a short expiry. Every result now carries resultType, with complete as the ordinary value.
Streamable HTTP requests must carry Mcp-Method and Mcp-Name headers (alongside MCP-Protocol-Version), so gateways and rate limiters can route and meter by method and tool without reading the body, and a header that disagrees with the body is rejected with a HeaderMismatch error (-32020). Tools can also expose selected parameters as headers through x-mcp-header. Results from tools/list, prompts/list, resources/list, resources/templates/list and resources/read must include ttlMs and cacheScope (public or private), and servers should list tools in a deterministic order so caches and LLM prompt caches hit. Change notifications move to a single opt-in subscriptions/listen stream, and SSE resumability is removed: a broken stream loses the in-flight request, which the client must re-issue.
Authorization changes: Dynamic Client Registration (RFC 7591) is deprecated in favour of Client ID Metadata Documents, where the client_id is an HTTPS URL pointing to a JSON document with the client's name and redirect URIs, which the authorization server fetches and validates. The recommended order is pre-registration, then CIMD where the server advertises client_id_metadata_document_supported, then DCR as a fallback. Clients must validate the RFC 9207 iss parameter when it is present, must key stored credentials by issuer and never reuse them with another authorization server, and must send an application_type when they do use DCR. Tool inputSchema and outputSchema may now use any JSON Schema 2020-12 keyword, and Tasks move out of the core into the io.modelcontextprotocol/tasks extension with polling via tasks/get.
The specification is free and open; there is nothing to sign up for. What you need is an SDK that speaks 2026-07-28. The MCP blog says the Tier 1 SDKs (TypeScript, Python, Go, C#) support it, with Rust in beta. The Python SDK's v2 line is the stable release for this revision and, per its docs, one server answers both 2025-era clients that send initialize and 2026-era stateless requests with nothing to configure.