Preface¶

The Model Context Protocol (MCP) is an open protocol that connects AI applications with external tools and data sources. First released by Anthropic in November 2024, it was donated to the Agentic AI Foundation (AAIF) under the Linux Foundation in December 2025, and has now become a widely adopted integration standard for platforms including Claude, Cursor, VS Code, and ChatGPT. According to official Anthropic data, monthly downloads of the MCP SDK have exceeded 400 million, a roughly 4x increase from the beginning of the year.

On July 28, 2026, MCP officially released the 2026-07-28 specification—this is the largest revision since the protocol launched. The core changes can be summarized in one sentence: the protocol layer has been fully statelessized. The initialize handshake and Mcp-Session-Id session header have been removed, and remote MCP servers can now be deployed like regular HTTP APIs on Serverless, edge nodes, and behind standard load balancers; MCP Apps and Tasks have graduated to official extensions; and the OAuth 2.0 authorization specification has been simultaneously strengthened. The full Claude product line has begun gradual support for the new specification. This article organizes the technical highlights and migration ideas for this update based on the official MCP blog, Anthropic announcements, and community discussions.

Stateless Core: Say Goodbye to Handshakes and Sessions¶

Problems with the Old Model¶

In the 2025-11-25 version, calling tools via Streamable HTTP required first establishing a session. The client sent an initialize request, the server returned an Mcp-Session-Id, and every subsequent call had to carry this header, with requests “pinned” to the instance that issued the session. Production environments thus often required:
- Sticky sessions or session-affinity routing
- Shared Session Stores (Redis, etc.)
- Gateways needing deep parsing of JSON-RPC bodies at the L7 layer to perform routing and rate limiting

This created significant operational overhead for teams wanting to deploy MCP servers on Lambda, Cloudflare Workers, or standard Kubernetes round-robin load balancers. MCP gateway/registry operators (such as Glama) also confirmed in community feedback that a significant proportion of compatibility issues were related to session state persistence.

New Model: Single Self-Contained Request¶

2026-07-28 condenses a single tool call into one self-contained HTTP request that any instance can handle:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
           "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

Six SEPs (Specification Enhancement Proposals) collaborated to complete this transformation:
1. SEP-2575: Remove the initialize/initialized handshake. The protocol version, client information, and capabilities are now carried in the _meta field of each request; when server capabilities need to be known in advance, the new server/discover method can be called.
2. SEP-2567: Remove the Mcp-Session-Id and the protocol-layer session concept.
3. SEP-2243: Streamable HTTP transport now mandates the Mcp-Method and Mcp-Name headers, allowing load balancers and gateways to route by operation type without parsing the request body; the server should reject requests where headers and body do not match.
4. SEP-2549: List results such as tools/list now carry ttlMs and cacheScope (similar to HTTP Cache-Control), allowing clients to cache responses safely and reduce repeated fetch operations.
5. SEP-2260 + SEP-2322: Server-initiated client interactions (such as deletion confirmations) have been changed to a Multi Round-Trip mode, returning an InputRequiredResult, with the client retrying with inputResponses and requestState—no persistent SSE connections are required throughout the process.
6. SEP-414: Standardize W3C Trace Context (traceparent, etc.) in _meta to enable end-to-end OpenTelemetry tracing.

Stateless Protocol ≠ Stateless Applications¶

The protocol no longer manages sessions on your behalf, but businesses can still pass state across calls using “explicit handles”: the server can mint a basket_id or browser_id in the tool’s return value, which the model passes back as a regular parameter in subsequent calls. Official documentation notes that this pattern is often more flexible than sessions hidden in the transport layer—models can combine, reason about, and pass these identifiers across multi-step tasks.

Extension Framework: MCP Apps and Tasks Officially Graduate¶

The 2025-11-25 version lacked a formal governance process for extensions. The 2026-07-28 release established the Extensions Track via SEP-2133: extensions are identified by reverse-DNS IDs, maintained in independent ext-* repositories, with versions decoupled from the core specification, and clients/servers negotiate enabled extensions via the extensions map in capabilities.

MCP Apps (SEP-1865)¶

Servers can declare interactive HTML UI templates, which hosts render in sandboxed iframes. Templates can be prefetched, cached, and security-reviewed; UI-side operations still use JSON-RPC, sharing audit and authorization paths with direct tool calls. Claude already supports MCP Apps, allowing users to operate connector UIs inline in conversations without switching tabs.

Tasks Extension¶

Tasks first appeared as an experimental core feature in 2025-11-25; production practice has shown their lifecycle is better suited for an independent extension. The new process adapts to the stateless model:
- The server can return a task handle for tools/call
- Clients use tasks/get, tasks/update, and tasks/cancel to drive progress
- Task creation is determined by the server (clients only need to declare support for the extension)
- tasks/list has been removed (cannot be safely scoped without sessions)

If you previously integrated with the legacy experimental Tasks API, you will need to migrate to the new lifecycle.

OAuth 2.0 Authorization Hardening¶

Six SEPs have brought MCP authorization closer to real-world deployment patterns for enterprise IdPs (Entra, Okta, etc.). Key points include:
- SEP-2468: Clients must validate the iss parameter in authorization responses (RFC 9207) to mitigate mix-up attacks; future versions may enforce rejection of responses missing the iss field.
- SEP-837: Declare the OpenID Connect application_type during Dynamic Client Registration to avoid desktop/CLI clients being incorrectly defaulted to "web", which would reject localhost redirects.
- SEP-2352: Registration credentials are now bound to the authorization server issuer, requiring re-registration when resources are migrated.
- SEP-2207 / SEP-2350 / SEP-2351: Add refresh token requests, step-up scope accumulation, and .well-known discovery suffix specifications.

Claude already offers Enterprise-managed auth: administrators authorize connectors once in the IdP, users inherit access via existing groups, and first-time login enables zero-touch access.

Other Notable Changes¶

Migration and Production Deployment Recommendations¶

This is a breaking change. The official RC was locked on May 21, 2026, with the final specification released on July 28; Tier 1 SDKs are expected to follow within the 10-week validation window.

Community assessments (including Hacker News discussions) generally agree that:
1. Bidirectional protocol incompatibility: Upgrading the SDK alone is often insufficient; servers and clients may need to refactor their transport layer and handshake logic.
2. Large SSE-only legacy deployments: Although SSE has been deprecated, most existing implementations still only support the old Streamable HTTP + session mode, extending the migration timeline.
3. Increased gateway value: During the transition period with coexisting protocol versions, MCP gateways can act as interoperability layers, performing protocol conversion between old clients and new stateless servers.

If you are planning a production rollout, you can proceed in the following order:
1. Review the official changelog and draft specification, and assess the impact surface against the SEP list.
2. Remove dependencies on initialize and Mcp-Session-Id; inject the _meta field and MCP-Protocol-Version header into every request.
3. Implement ttlMs caching for tools/list responses; use Mcp-Method/Mcp-Name at the gateway layer for routing and rate limiting.
4. If you are using the experimental Tasks API or depend on Roots/Sampling, develop a migration timeline based on the deprecation list.
5. Check if your AS returns an iss field for authorization, and update CLI/desktop clients to declare the DCR application_type.
6. Monitor the Tier 1 SDK support progress for your chosen tools; Claude Connectors directory submissions will need to comply with the new specification requirements.

Conclusion¶

The 2026-07-28 update advances MCP from “an Agent private protocol requiring session affinity” to “a stateless workload that can run on commodity HTTP infrastructure”. Combined with the extension framework, formal deprecation policies, and OAuth hardening, this is a foundational step for MCP to move towards large-scale enterprise production deployments. The cost is clear migration overhead—but as MCP maintainers responded on HN, this is a long-awaited change for developers looking to deploy remote MCP servers on Serverless. The AAIF community held a Release Party around July 28, 2026, with SDK and Claude product support still rolling out; it is recommended to validate your workloads on the new specification as early as possible, rather than waiting for the legacy session model to be fully phased out.