On July 29, 2026, Beijing time, the Model Context Protocol project released the stable specification for 2026-07-28. The official GitHub tag was published at midnight forty-seven minutes past. The project's official blog, signed by chief maintainers David Soria Parra and Den Delimarsky, explicitly referred to this release as a new version launch rather than the candidate version announced in May. The core of the specification changed from a bidirectional stateful protocol to a stateless request-response model, with accompanying software development kits (SDKs) updated on the same day. Stable specifications and change logs were simultaneously published on the project's public documentation site.
Changes in Session Lifecycle
The new version removed the initialize and initialized handshake and canceled the Mcp-Session-Id request header in Streamable HTTP. Each request now carries protocol version, client identity, and client capabilities within _meta, with servers providing their own information in results. Servers must implement server/discover remote procedure calls (RPCs), which clients can call before making business requests to understand supported versions, capabilities, and identities or directly issue self-describing requests.
The stateless core allows any request to fall on any server instance behind a regular round-robin load balancer without requiring shared session storage by the protocol. The new version also requires Streamable HTTP POST requests to carry Mcp-Method and Mcp-Name, allowing routing or metering based on method and tool name when passing through gateways, rate limiters, or web application firewalls. Applications that need to preserve state across calls can still generate explicit handles via the server and pass them as regular tool parameters to models.
Multi-round Requests, Notifications, and Caching
Multi-round request-response has become a new handling model for when additional information is needed. If confirmation or missing parameters are required during tool execution, servers return an intermediate result with resultType set to input_required and list the necessary content in inputRequests; clients then resubmit the same call with inputResponses and the original requestState after collecting answers. Server-initiated requests that previously relied on continuous bidirectional connections have been rewritten, with change notifications concentrated into subscriptions/listen response streams where notification types are chosen by the client. Progress and message notifications associated with specific requests continue to be passed through their respective response streams.
Tool lists, prompts, resource lists, and resource read results now must provide ttlMs and cacheScope, indicating freshness hints and public or private caching scope respectively. The specification also requires tool lists to use a deterministic order so that client reconnections can maintain more stable upstream prompt caches. Distributed tracing fields are fixed within _meta, using traceparent, tracestate, and baggage conventions to connect OpenTelemetry records across different SDKs and gateways. No full ecosystem cost or performance comparison tests were provided by the official side.
Authorization and the Tasks Extension
The authorization section requires clients to validate the RFC 9207 issuer parameter appearing in authorization responses and bind registered credentials to the authorizing server that created them; credentials must not be reused when the issuer changes. Dynamic client registration also needs to declare a suitable application_type to handle native redirect URIs for desktop applications and command-line programs. DCR has been listed as deprecated, with CIMD becoming the standard mechanism. These clauses target specific authorization flows, and the public specification does not claim they cover prompt injection, malicious tools, or deployment permission errors.
Experimental Tasks have been moved out of the core protocol to become an official extension at io.modelcontextprotocol/tasks; the new version polls task status with tasks/get and submits client input using tasks/update while removing tasks/list. On the day of release, four first-level SDKs—TypeScript, Python, Go, and C#—already supported the 2026-07-28 specification, with Rust in testing phase. The official list only describes the status of these SDKs without listing migration progress for all clients, servers, or third-party implementations.
Deprecation Policy and Adoption Data
Roots, Sampling, Logging, dynamic client registration, and old HTTP plus server-sent event transmission have entered a deprecation lifecycle but are not immediately removed: related functionalities can still be used during the backward compatibility period. New policies stipulate that at least twelve months must elapse from entering deprecation to earliest removal. The official change log also notes that the stable version contains breaking changes compared to 2025-11-25, requiring implementations dependent on session identifiers, old handshakes, task interfaces, or old notification methods to be modified according to corresponding migration guidelines. The new version also removes resumption of server-sent events; after a response stream interruption, clients must resubmit with a new request number.
The MCP project reports that the four first-level SDKs collectively have nearly 500 million monthly downloads, with TypeScript and Python toolkits each exceeding one billion cumulative downloads. The public release did not include independent audits or per-package statistical methods, nor can download counts be converted into active users, institutions, or production deployments. VentureBeat's publicly titled article by Michael Nuñez summarized the update as stateless architecture, strengthened authorization, and a twelve-month deprecation policy, consistent with the official theme. Existing public materials do not provide full ecosystem migration rates, independent performance benchmarks, migration costs, incident rates, or economic impacts.