The biggest MCP spec update ships July 28: What changes for AI agent authentication

On May 21, 2026, the Model Context Protocol's lead maintainers published the release candidate for MCP 2026-07-28. They called it "the largest revision of the protocol since launch." That's not marketing language. The spec removes sessions, drops the initialization handshake, deprecates three core features, rewrites how authorization works, and introduces a framework for extensions that will shape how the protocol evolves from here.

The final specification ships on July 28, 2026. The ten-week window between the release candidate and the final spec is for SDK maintainers and server implementers to validate the changes against real workloads. If you're running MCP servers in production, that window is your migration timeline.

This article covers what's actually changing, verified against the official release candidate blog post and the draft specification. It focuses on the changes that matter most for teams building and securing agentic applications: the shift to a stateless core, the authorization hardening, and what you need to update before July 28.

The protocol goes stateless

The headline change is that MCP no longer manages sessions at the protocol layer. Six Specification Enhancement Proposals (SEPs) work together to remove the session model that the 2025-11-25 spec was built on.

The initialize/initialized handshake is gone. In the previous spec, every MCP connection started with a two-step handshake where the client and server exchanged protocol versions, capabilities, and identity information. In 2026-07-28, that handshake is removed entirely (SEP-2575). The protocol version, client info, and client capabilities now travel in _meta on every request. A new server/discover method lets clients fetch server capabilities on demand rather than up front.

The Mcp-Session-Id header is gone. The protocol-level session that pinned a client to a specific server instance is removed (SEP-2567). This is the change with the biggest operational impact. In the previous spec, a remote MCP server needed sticky sessions, a shared session store, and deep packet inspection at the gateway to route requests to the right instance. In 2026-07-28, any server instance can handle any request.

The practical result: an MCP server can now run behind a plain round-robin load balancer. No sticky routing, no shared session store. The server routes traffic using the new Mcp-Method and Mcp-Name headers (SEP-2243) and can let clients cache tools/list responses for as long as the server's ttlMs permits.

Stateless protocol, stateful applications. Removing the protocol-level session doesn't mean your application has to be stateless. Servers that need to carry state across calls can mint explicit handles (a basket_id, a browser_id) from a tool and have the model pass that handle back as an ordinary argument on later calls. As the release candidate blog post notes, this pattern is often more powerful than hidden session state because the model can reason about the handles, compose them across tools, and hand them off between steps.

Authorization gets real

The previous MCP spec's approach to auth was, charitably, "bring your own token." The 2026-07-28 spec aligns MCP authorization with OAuth 2.1 and OpenID Connect in ways that make it meaningfully enterprise-ready.

• ‍MCP servers are now formally OAuth 2.1 resource servers. This was introduced in the 2025-11-25 spec but 2026-07-28 tightens it considerably. MCP servers MUST implement OAuth 2.0 Protected Resource Metadata (RFC 9728) so clients can discover the correct authorization server automatically. MCP clients MUST implement Resource Indicators (RFC 8707) to explicitly specify which MCP server a token is intended for, preventing a malicious server from obtaining tokens meant for a different server.‍
• Client ID Metadata Documents replace Dynamic Client Registration. The spec now recommends OAuth Client ID Metadata Documents (CIMD) as the preferred method for client registration. Dynamic Client Registration (RFC 7591) is deprecated and retained only for backward compatibility with authorization servers that don't support CIMD yet.‍
• Issuer verification is now required. Clients must validate which authorization server issued an authorization response (based on RFC 9207) and must bind registered credentials to the issuing authorization server's issuer. If a resource migrates between authorization servers, the client must re-register (SEP-2352). This prevents a class of mix-up attacks that were possible when one client talks to many MCP servers, which is exactly the deployment pattern MCP encourages.‍
• Refresh token handling is formalized. The spec now documents how to request refresh tokens from OpenID Connect-style authorization servers (SEP-2207) and clarifies scope accumulation during step-up authorization (SEP-2350). In the previous spec, refresh token behavior was undefined, which meant every implementation handled it differently.‍
• Application type declaration during registration. Clients now declare their OpenID Connect application_type during registration (SEP-837), which solves a common failure mode where an authorization server defaults a desktop or CLI client to "web" and then rejects its localhost redirect URI.

The cumulative effect of these changes is that MCP authorization goes from "technically possible if you wire everything up yourself" to "follow these RFCs and it works." For teams running MCP servers behind enterprise identity providers (Okta, Azure AD, Google Workspace), the path from "unauthenticated MCP server" to "properly secured MCP server" is now defined at the spec level rather than left as an exercise.

Extensions become first-class

The 2026-07-28 spec introduces a formal extensions framework. Extensions get reverse-DNS identifiers, their own repositories, delegated maintainers, and versions that move independently from the main spec. Clients and servers negotiate extension support through an extensions map in their capabilities.

Two extensions ship with the release candidate:

• ‍MCP Apps let servers render interactive HTML UIs directly in the client. The rendered UI communicates back to the host over the same JSON-RPC protocol used everywhere else in MCP, which means every UI-initiated action goes through the same audit and consent path as a direct tool call. This is the primitive that could turn MCP from a developer integration layer into a user-facing ecosystem.‍
• Tasks provide first-class support for long-running async work. Tasks were an experimental core feature in 2025-11-25, but production use revealed enough design issues that they've been moved to an extension and substantially redesigned. A server can respond to tools/call with a task handle, and the client drives the lifecycle with tasks/get, tasks/update, and tasks/cancel. The tasks/list endpoint is removed because it couldn't be scoped safely without sessions. Anyone who built against the experimental Tasks API in 2025-11-25 will need to migrate to the new lifecycle.

What's deprecated

Three features are deprecated in this release:

• ‍Roots are replaced by Resource URIs (plain URLs).
• ‍Sampling is removed from the core spec and may return as an extension.
• ‍Logging is also removed from the core spec.

The spec now includes a formal deprecation policy. Deprecated features are documented, continue to work during a transition period, and are eventually removed with clear timelines. This is the first time MCP has had a structured process for evolving the spec without breaking existing implementations.

What you need to do before July 28

If you're running MCP servers in production, here's the migration checklist:

• ‍Check for session dependencies. Find every place your server stores or reads state tied to Mcp-Session-Id. Replace session-based state with explicit handles that the client passes as tool arguments. If you're using sticky routing at the load balancer, you can remove it once the migration is complete.‍
• Update your authorization implementation. If your server accepts unauthenticated connections, this is the time to add OAuth 2.1. The spec now requires Protected Resource Metadata (RFC 9728), so your server needs to expose a .well-known/oauth-protected-resource endpoint or include resource_metadata in WWW-Authenticate headers. If you're using Dynamic Client Registration, plan your migration to Client ID Metadata Documents.‍
• Update tool schemas. The spec now supports full JSON Schema 2020-12 for tool input schemas, replacing the previous restriction to a JSON Schema subset. Review your tool definitions and update if you were working around schema limitations.‍
• Check for Roots, Sampling, and Logging usage. If your server uses any of these, start planning the migration. Roots become Resource URIs. Sampling and Logging move out of the core spec.‍
• Update your MCP client. Clients must now include MCP-Protocol-Version, Mcp-Method, and Mcp-Name headers on every request. The initialize handshake is gone; use server/discover to fetch server capabilities. Resource Indicators (RFC 8707) are required in token requests.‍
• Test multi-instance deployments. Once session dependencies are removed, deploy multiple server instances behind a round-robin load balancer and run your test suite. Any test that fails has a hidden session dependency you missed.

What this means for agent security

The 2026-07-28 spec is a significant step forward for the security model described in this series. The previous articles on agent credentials, supply chain verification, tool invocation policy, and prompt injection containment were written against the 2025-11-25 spec. The security architecture in those articles still applies, but the new spec makes several of those patterns easier to implement.

Scoped, per-agent credentials are simpler with the stateless model. Each request is self-contained, which means token validation happens once per request without session context. The Mcp-Method and Mcp-Name headers make it trivial to route different tool calls through different authorization policies at the gateway layer, before they even reach your server code.

Resource Indicators (RFC 8707) directly address the confused deputy problem described in the delegation article. When a client requests a token, it must specify which MCP server the token is for. A token minted for Server A can't be replayed against Server B. This is enforced at the protocol level rather than relying on application-level checks.

The extensions framework means that security-relevant capabilities like audit logging, consent UIs, and approval flows can be standardized as extensions rather than reimplemented by every server author. MCP Apps already route UI actions through the same JSON-RPC consent path as tool calls, which means your invocation policy layer doesn't need a separate code path for UI-initiated actions.

Securing AI agents and MCP servers with WorkOS

WorkOS AuthKit already acts as a spec-compliant OAuth 2.1 authorization server for MCP. The 2026-07-28 spec changes align with what WorkOS already provides: Protected Resource Metadata discovery, Resource Indicators, PKCE for public clients, and enterprise SSO integration through the same authorization server. For teams migrating to the new spec, WorkOS handles the authorization server side so you can focus on updating your MCP server and client code. See the MCP Auth documentation for implementation details.