MCP becomes web infrastructure

On 28 July 2026, the Model Context Protocol project released MCP 2026-07-28, its fifth specification revision and its broadest wire-level reset since launch. The scale around that decision is already unusual for a protocol not yet two years old. The project reports close to half a billion monthly downloads across its Tier 1 SDKs, with the TypeScript and Python SDKs each past one billion total downloads. Anthropic reports more than 950 servers in Claude’s connectors directory, used by millions of people each day.

Those are first-party figures, and package downloads are not unique developers or deployed servers. A directory count is not an interoperability test. They still establish why this release matters: a protocol with meaningful production traffic has chosen to break its transport model now rather than preserve an architecture its operators had learned to work around.

In May, we explained MCP as the standard that stops integration cost from compounding. That argument still holds. This release changes the infrastructure underneath it. A remote MCP server is no longer exposed as a protocol session that must be initialized and then kept coherent. It now receives self-describing HTTP requests that ordinary gateways, caches, load balancers and stateless workers can operate.

The session was the deployment tax

Under 2025-11-25, a client began with initialize, completed notifications/initialized, received an Mcp-Session-Id when the server used sessions, and returned that identifier on later HTTP requests. At one instance, this was manageable. Across a fleet, it meant sticky routing, a shared session store, or application code that carefully avoided the protocol state it had been given.

The new revision removes the handshake and the session identifier. Every request declares its protocol version and client capabilities in _meta; clients should also identify themselves on each request. Servers must implement server/discover so a client can inspect versions and capabilities up front, but discovery is optional for the client. It can make an operation directly and handle a structured unsupported-version response.

That is the architectural break. An ordinary request no longer depends on traffic that reached the server before it. Any instance can handle it.

Stateless does not mean the application cannot have state. If a shopping basket, browser process or long-running workflow must survive across calls, the server mints an explicit handle and the model passes it back as a tool argument. State moves out of hidden transport context and into application data the model and the server can reason about. That is simpler to route, but a handle is not authentication. In a protected deployment, make handles unguessable, expire them where practical and authorize access to their state against the authenticated caller on every request.

The rest of the web stack can see MCP

Removing sessions would be a deployment improvement on its own. The surrounding changes make it an operating model.

Streamable HTTP requests now carry Mcp-Method; tools/call, resources/read and prompts/get also require Mcp-Name. A gateway can route, meter or apply policy to tools/call and a particular tool without parsing a JSON body. The server must verify that the headers agree with the body, so the optimization does not become a policy split between the edge and the origin.

Discovery, list and selected resource results now carry ttlMs and cacheScope. A client can cache a tool catalog for a declared period, and it knows whether that result is reusable across authorization contexts or private to one. Servers should keep tools/list in deterministic order, improving ordinary response caching and keeping tool catalogs stable for model prompt caches. W3C trace context has named _meta keys, so a trace can cross client, gateway, MCP server and downstream service without each SDK inventing a convention.

The protocol is stateless, not streamless. Request-scoped progress still flows on the response to the request that created it. A new subscriptions/listen operation opens an explicit stream for the change notifications a client selects. What disappears is the ambient GET stream, resumable SSE delivery and the assumption that one open connection owns the conversation.

Interaction becomes a result, then a retry

The hardest part of removing a bidirectional session is preserving the moments when a server needs something from the client halfway through work.

Multi Round-Trip Requests, or MRTR, replace standalone server-initiated requests for elicitation, sampling and roots. A tool can return resultType: "input_required" with the questions or confirmations it needs. The client gathers the answers and retries the original operation with a new JSON-RPC ID, the input responses and, when the server supplied it, the opaque requestState. Any instance can receive that retry because the exchange carries its own context.

This is a cleaner human-approval path for a stateless service, but it is not exactly-once execution. An interrupted mutating request may be issued again. Servers still need idempotency where duplicate effects matter and, when they include requestState, integrity protection if changing that state could affect authorization or business logic.

The same separation shapes extensions. MCP Apps, Tasks and Enterprise-Managed Authorization now sit on a formal, independently versioned extension track. Apps let servers provide interactive HTML that a supporting host renders in a sandbox. Tasks use durable handles and polling for long-running work. Enterprise-Managed Authorization lets an identity provider drive centrally managed connector access. They are not new core guarantees: extensions are disabled by default, explicitly negotiated and supported unevenly across clients and SDKs.

A migration, not a switch-off

The final specification and Tier 1 SDK support are live. Existing servers did not stop working on 28 July. The old and new wire models are nevertheless different enough that mixed fleets need deliberate compatibility.

Modern-only and legacy-only implementations do not speak the same opening exchange. The official SDKs provide migration paths: a dual-era client can probe and fall back, and some server SDKs can serve both revisions from one endpoint. Upgrading an SDK major version and enabling the new wire revision can also be separate decisions. The safe order is server compatibility first, gateway support second, modern-first dual-era clients third, and legacy removal only after observed fallback traffic reaches zero.

Authorization and governance are infrastructure

The release also tightens the parts that usually consume the most integration time.

Authorization servers should return the RFC 9207 iss value and clients must validate a present issuer against the issuer recorded from server metadata before redeeming a code. If that metadata advertised issuer support, the client must also reject an authorization response that omits iss. Persisted client credentials are bound to the issuer that created them and cannot be reused when a protected resource moves to a different authorization server. Native and CLI clients now declare the correct OpenID Connect application type during Dynamic Client Registration, avoiding the common failure where localhost redirects are treated as hosted web callbacks.

Dynamic Client Registration is itself deprecated in favor of Client ID Metadata Documents. Roots, Sampling and Logging are also deprecated for new implementations, with documented replacement paths. A formal feature lifecycle now distinguishes Active, Deprecated and Removed features and normally provides at least twelve months before removal. The important change is not that old features vanish today. It is that an architecture team can inspect one registry and know what not to build into a new system.

Claude is adopting the protocol, not defining it

Anthropic announced support for the new revision across Claude products, but its exact wording matters: support is rolling out “soon.” On 29 July, public connector documentation still described older protocol support on some surfaces, and Anthropic had not published a product-by-product matrix or said that Claude supports the new Tasks extension everywhere.

Several capabilities in the announcement already existed as separate Claude features. MCP Apps had shipped across Claude apps and Cowork. Enterprise-managed authorization was in beta for Team and Enterprise customers. Published connectors had an observability dashboard, and MCP tunnels were a research preview for reaching private-network servers. Those are evidence of Anthropic investing around MCP, not evidence that every Claude client has already completed the wire migration.

The distinction matters because MCP is open infrastructure under community governance. The specification, SDKs and extensions can be implemented by any host. Claude is a consequential adoption surface, and its directory metrics are a strong distribution claim, but Claude’s rollout calendar, product limits, retention rules and connector review process are product behavior, not protocol semantics.

Audit the architecture, not the version string

For a technical decision-maker, declaring support for 2026-07-28 is the beginning of the review. Six checks determine whether the system has actually adopted the architecture.

1. Find every hidden session dependency. Inventory initialize, Mcp-Session-Id, sticky routes and shared protocol-session storage. If an operation needs continuity, name the application handle that replaces each dependency and the instance-independent store behind it.
2. Prove mixed-version behavior. Test modern discovery, structured version errors, legacy initialization and dual-era fallback against real clients and servers. A new SDK package does not prove the endpoint is serving the new wire revision.
3. Make retries safe. Exercise MRTR, broken response streams and mutating calls. Protect opaque request state when it is present and security-sensitive, use new request IDs as required, and add application-level idempotency where a repeated effect would be harmful.
4. Treat headers and caches as policy. Route on MCP headers only when the origin validates them. Default caller-varying data to private caching, keep authorization context in the cache key and invalidate catalogs when subscribed changes arrive.
5. Rebuild the authorization boundary. Validate issuers and key credentials by issuer. In protected deployments, authenticate every request and authorize explicit state-handle access against the principal. Stateless routing removes a protocol-session store; it does not remove identity or ownership.
6. Separate core, extensions and deprecations. Negotiate Apps, Tasks and enterprise auth instead of assuming them. Record where Roots, Sampling, Logging, DCR and legacy HTTP+SSE remain, then migrate by observed use rather than by announcement date.

MCP has not become simple. It has become ordinary in the useful sense: its routing, state, caching, retries, identity and evolution can now be designed with the same explicit tools as the rest of a production HTTP system. That removes a deployment constraint. It also removes the excuse for leaving those decisions hidden inside the connection.