MCP 2026-07-28 Spec: Stateless Core and Agent Auth Overhaul

The Largest MCP Revision Since Launch

With the final Model Context Protocol specification for 2026-07-28 set to publish on 28 July 2026, engineering teams have eight days to review the breaking changes in the release candidate that has been under validation since May 2026. The MCP team describes this as the most significant update to the protocol since its initial release — and by the scope of what it changes, that description is accurate. Three architectural shifts define the 2026-07-28 spec: a stateless core that removes the protocol-level session entirely, six OAuth Security Extension Proposals that bring agent authentication closer to modern identity standards, and two new extensions — MCP Apps for server-rendered user interfaces, and Tasks for long-running asynchronous work. The ten-week validation window closes with the final spec on 28 July; Tier 1 SDK maintainers are expected to ship support within that window.

Stateless Core: What Changes for Servers

The previous MCP specification required remote servers to maintain protocol-level sessions identified by an Mcp-Session-Id header. This made horizontal scaling expensive: a load balancer had to route every request from a client session to the same server instance, through sticky sessions or a shared session store. The 2026-07-28 RC removes the Mcp-Session-Id header and the associated session layer entirely. Any MCP request can now land on any server instance behind a plain round-robin load balancer. Routing happens on the Mcp-Method header instead. List and resource read results now carry ttlMs and cacheScope fields that tell clients exactly how long a tools/list or resources/list response remains valid, and whether it is safe to share across users — allowing clients to cache tool lists aggressively without stale-data risk.

Application State Without Protocol Sessions

Removing the protocol-level session does not require servers to be stateless at the application layer. Servers that need to carry state across calls — a browser session, a workflow in progress, a task basket — mint an explicit application handle such as a browser_id or basket_id, return it as a tool result, and tell the model to pass it back as an argument on subsequent calls. The state lives in the application layer, not the protocol layer, which is architecturally the correct location. This design separates what was previously a conflation of two concerns: connection management (now stateless at the protocol level) and application continuity (still managed at the application level).

OAuth Hardening: Six Requirements for Agent Authentication

Six OAuth Security Extension Proposals tighten the authentication surface of MCP connections in the 2026-07-28 spec. Clients must now validate the iss parameter per RFC 9207 to prevent mix-up attacks in environments where a single client interacts with multiple authorisation servers. MCP servers must publish OAuth 2.0 Protected Resource Metadata at a well-known URI per RFC 9728, allowing clients to discover authorisation server details automatically without out-of-band configuration. Clients must implement Resource Indicators per RFC 8707, explicitly binding a token to the specific MCP server it was issued for and preventing token reuse across servers. OpenID Connect Dynamic Client Registration now requires an application_type declaration during registration. Together, these six requirements align MCP authorisation with the identity standards that enterprise IT and cloud security teams already evaluate against existing controls — reducing the friction of deploying MCP-based agents in regulated environments.

MCP Apps and the Tasks Extension

The MCP Apps extension lets a server ship an interactive HTML user interface that a host renders inside a sandboxed iframe. Every action triggered from the UI — a button press, a form submission — goes through the same JSON-RPC audit and consent path as a direct tool call, preserving the protocol's security model without restricting the richness of what the server can display. Servers declare their UI templates ahead of time so hosts can prefetch, cache, and security-review them before a user session begins.

The Tasks extension addresses a persistent gap in the current protocol: there is no standard mechanism for a server to represent work that takes seconds, minutes, or longer and must be polled or streamed until completion. Tasks provides exactly that mechanism, enabling servers to expose long-running agentic operations — a code review across a large repository, a document generation pipeline, a multi-step data extraction workflow — as first-class protocol objects with status and result fields that clients can query or subscribe to.

What the 2026 Spec Means for Teams Building Agentic Products

For engineering teams building MCP servers or integrating MCP into agentic product architectures, the 2026-07-28 spec has two practical implications. The first is infrastructure cost. Removing the session layer means MCP servers in cloud environments can scale horizontally behind standard load balancers without sticky sessions or distributed session stores. For teams running high-volume agentic workloads, that reduction in infrastructure complexity translates directly into lower operational cost and simpler deployment architecture — no session store to provision, no sticky routing to configure, no session affinity to maintain at the load balancer.

The second implication is enterprise readiness. The six OAuth requirements bring MCP agent authentication to a standard that enterprise security teams can evaluate against existing controls. Teams building agentic products for enterprise clients — particularly in banking, insurance, healthcare, and regulated sectors in India — will find the 2026-07-28 spec substantially easier to clear through corporate security review than the current specification, because the authentication surface now maps to protocols those security teams already know and can audit.

The Bottom Line

The 2026-07-28 MCP specification release candidate — finalised on 28 July 2026 — is the most significant update to the protocol since launch. Its three core changes are a stateless protocol layer that removes sticky-session requirements from server infrastructure, six OAuth hardening requirements that align agent authentication with enterprise identity standards, and two new extensions — MCP Apps for server-rendered interactive interfaces, and Tasks for long-running asynchronous work. Tier 1 SDK maintainers have a ten-week window to ship support. For teams building or deploying AI agents using MCP, the 2026-07-28 spec simplifies horizontal scaling, strengthens authentication security, and expands the protocol's expressive range — making it a meaningfully better foundation for production agentic applications than what shipped at launch.