Preface

The Model Context Protocol (MCP) is an open standard for connecting AI Agents with external tools and data sources. Since its launch by Anthropic in November 2024, it has quickly become the de facto “connectivity layer” for Agent workflows—vendors including Anthropic, Google Cloud, Microsoft, AWS, and Cloudflare all recognize it as a critical component of Agent infrastructure.

On July 28, 2026, the MCP maintenance team officially released the 2026-07-28 specification under the stewardship of the Agentic AI Foundation (AAIF), a subsidiary of the Linux Foundation. This is the most significant upgrade to MCP since the launch of remote MCP over a year ago: the protocol core has shifted from a bidirectional stateful model to a stateless request/response architecture, while also hardening OAuth authorization, establishing an official extension framework, and graduating capabilities such as MCP Apps and Tasks to official extensions.

According to the official MCP blog, monthly downloads of Tier 1 SDKs (TypeScript, Python, etc.) have neared 500 million, with cumulative downloads of the TypeScript and Python SDKs both exceeding 1 billion. Anthropic also disclosed that monthly downloads of the MCP SDK have exceeded 400 million this year, representing an approximate 4x growth. VentureBeat, citing joint maintainer David Soria Parra, reported that weekly SDK downloads have reached approximately 250 million. Behind these figures is a wave of enterprises moving MCP from pilot projects to production environments.

This article is based on the official MCP release notes, the Anthropic Claude product blog, and VentureBeat interviews, outlining the core changes in this update, their practical impact on developers, and the breaking changes to note during migration.

Why a Stateless Core?

In the legacy design, MCP clients were required to maintain persistent sessions with specific server instances. Clients had to complete the initialize/initialized handshake and identify sessions via the Mcp-Session-Id header. In modern cloud environments such as Kubernetes and Serverless, compute nodes scale up and down dynamically, and instances behind load balancers are not fixed—once a Pod holding session state goes offline, Agent work may be interrupted.

Joint maintainer Den Delimarsky told VentureBeat in an interview: “Previously you needed a session store to manage session IDs; if a compute pod crashed, requests would fail. That is no longer an issue in the new version.” AAIF Executive Director Mazin Gilbert compared the change to the stateless design of the Web itself—browsers do not need to “stick” to a specific server to access any website.

The 2026-07-28 specification officially deprecates protocol-level handshakes and session headers (SEP-2575, SEP-2567). Every request is self-describing, carrying protocol version, client identity, and capabilities in the _meta field; any request can be routed to any instance behind a load balancer without requiring shared storage or sticky routing. If a client wishes to learn server capabilities in advance, it can call the optional server/discover RPC, but this is not mandatory.

It is important to emphasize: protocol-level statelessness does not mandate application-level statelessness. If context needs to be passed between tool calls, the server can explicitly return a handle, which the model will pass back as a parameter in subsequent calls—state is managed by developers on demand, rather than hidden in the transport layer.

What Does a Stateless Request Look Like?

The official blog provides a typical request example under Streamable HTTP:

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

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

Key points:
1. No Mcp-Session-Id: Each POST request is independent and complete, and can be routed to any backend.
2. Mcp-Method and Mcp-Name headers (SEP-2243): Gateways, WAFs, and rate limiters can directly route and authenticate based on headers without parsing the JSON body.
3. MCP-Protocol-Version: 2026-07-28: Explicitly declares the protocol version to facilitate multi-version coexistence and gray release.

For deployments, this means MCP Servers can run on stateless infrastructure like Cloudflare Workers, AWS Lambda, Netlify Edge, and other similar platforms just like regular HTTP services—Google Cloud, Cloudflare, Netlify, and others announced Day Zero support on the day of release.

MRTR: Interactive Calls Under a Stateless Protocol

A thorny issue with fully stateless protocols is: what if tool execution requires user confirmation or additional parameters mid-run? The legacy design relied on server-initiated requests such as elicitation/create and sampling/createMessage, and required maintaining a bidirectional long connection.

The new version introduces Multi Round-Trip Requests (MRTR, SEP-2322): the server returns resultType: "input_required" and a list of pending requests, and the client retries the original call with inputResponses attached. Supabase Product Lead Inian Parameshwaran noted in an official testimonial that MRTR enables support for elicitation flows such as “confirm costs before creating a project” and “confirm before deleting data” within a stateless architecture.

Legacy capabilities including Roots, Sampling, and Logging have been officially deprecated (SEP-2577), with a minimum 12-month retention period; new implementations should no longer use them. Legacy HTTP+SSE transport has also been marked for deprecation.

Cacheable List Responses

Responses to tools/list, prompts/list, resources/list, and resources/read now carry ttlMs and cacheScope (SEP-2549). Clients can use this information to develop caching strategies and reduce repeated pulls; deterministic list order also helps prompt caches remain stable after reconnections. This delivers direct performance benefits for Agent clients that frequently call tool directories.

Official Extension Framework: MCP Apps and Tasks

The 2026-07-28 specification formally locks in the extension mechanism. In addition to the core protocol, capabilities evolve independently as versioned extensions, preventing the core specification from becoming bloated.

MCP Apps allow servers to render interactive UIs—forms, dashboards, visualizations, etc.—during conversations, rather than only text output. Figma, Netlify, and others are already exploring embedding design files and generated results directly into Agent conversation interfaces.

Tasks (io.modelcontextprotocol/tasks extension, SEP-2663) have graduated from experimental core status, targeting long-running asynchronous tasks: the server returns a durable task handle, and clients can disconnect and resume tracking via poll-based tasks/get and tasks/update after restarting. AWS contributed the Tasks extension, and Amazon Bedrock AgentCore already supports deploying MCP Servers under the new specification. Change notifications have been migrated from the old HTTP GET endpoint to a subscriptions/listen stream where clients opt in by type.

Enterprise Managed Authorization (EMA) collaborates with identity providers such as Okta, enabling enterprise IdPs (such as Entra, Okta) to act as a unified access gate for MCP—administrators authorize once, and users inherit permissions via existing IdP groups. Products including Claude have implemented zero-touch connector configuration.

OAuth 2.0 Hardening and Enterprise-Grade Authorization

Maintainers acknowledge that authorization integration is one of the most time-consuming aspects of MCP deployment. The 2026-07-28 specification takes several steps to align with OAuth/OIDC:
1. RFC 9207 iss validation (SEP-2468): The authorization server returns an issuer, which the client must verify before exchanging a code, blocking mix-up attacks. Maintainers emphasized this is a preventative hardening measure, not a response to an exploited vulnerability.
2. Client credential binding to issuer (SEP-2352): Reuse of credentials across authorization servers is prohibited.
3. DCR officially deprecated, transitioning to CIMD (Client ID Metadata Documents): Dynamic Client Registration remains backward compatible but will be removed in future versions; issues with localhost redirects for CLI/desktop clients are also mitigated via SEP-837 changes such as application_type.

VentureBeat refers to the “12-month deprecation window + open standards + stateless extensibility” as the three pillars of enterprise trust—for Fortune 500 companies, security and predictable evolution are sometimes more critical than statelessness itself.

12-Month Deprecation Window

The specification officially introduces a formal deprecation policy for the first time: any deprecated feature must be retained for a minimum of 12 months before removal. Maintainers consulted with Google, Microsoft, Amazon, and other companies to select this window; telemetry shows most ecosystems complete upgrades within 6–8 months. Features including Roots, Sampling, Logging, and HTTP+SSE are being phased out under this policy.

SDK and Ecosystem Status

Tier 1 SDKs—TypeScript, Python, Go, C#—all support the 2026-07-28 specification and provide migration guides for breaking changes; the Rust SDK is in beta. The Claude Connector Directory now includes over 950 MCP Servers, with support for the new specification being gradually rolled out across Claude product surfaces.

Since AAIF was founded in December 2025, its membership has grown from approximately 40 to 240 companies; Anthropic’s contribution share has fallen below 50%. The joint maintainer team spans Anthropic, Microsoft, OpenAI, Google, Amazon, and other organizations, with core decisions typically approved unanimously—VentureBeat views this as a key milestone for MCP evolving from a single-vendor project to a neutral open standard.

Migration Recommendations for Developers

If you maintain an MCP Server or Client, we recommend evaluating in the following order:
1. Check for dependencies on session IDs or initialize handshakes—this is the largest breaking change. Official SDKs will absorb most of the changes, but custom transport layers will require manual adaptation.
2. Evaluate long-lived connection interactions—elicitation, sampling, and similar workflows should be migrated to the MRTR pattern.
3. Update OAuth integrations—enable iss validation and plan the transition from DCR to CIMD.
4. Leverage cache headers—implement reasonable TTLs for list responses on the client side to reduce cold start overhead.
5. Switch to the Tasks extension for long-running tasks—avoid maintaining fragile long connections for batch jobs.

Soria Parra stated that most projects based on official SDKs have manageable migration costs: “Pretty much any model in the world can make these changes in one shot”—this itself reflects the maintainers’ design considerations for AI-assisted upgrade paths.

Summary

The 2026-07-28 update is not an incremental patch, but an architectural leap for MCP toward enterprise-grade Agent infrastructure: a stateless core resolves scaling deployment bottlenecks, MRTR and Tasks extensions cover interactive and asynchronous scenarios, OAuth hardening and EMA address security requirements in production environments, and the 12-month deprecation policy provides a predictable evolution rhythm.

For teams building Agent workflows, this is the right window to align with the new specification using official SDKs and deploy MCP Servers on standard HTTP stacks. The protocol is still evolving rapidly—AAIF has already announced projects such as Agent Gateway—but as Gilbert’s analogy notes: HTTP took 30 years to become unnoticeable infrastructure; the “plumbing” of the Agent internet may finally start bearing real load with this stateless transition.

References
- The 2026-07-28 Specification | MCP Blog
- Bringing MCP 2026-07-28 to Claude | Anthropic
- MCP just got its biggest update ever | VentureBeat