The Model Context Protocol goes stateless, and starts a deprecation clock on Roots and Sampling

The Model Context Protocol, the open standard that lets AI assistants call external tools and read external data, shipped a new revision on July 28. It is the first update since last November’s 2025-11-25 spec, and the first since MCP moved from an Anthropic project to the connective tissue that OpenAI, Google, and a broad set of dev-tool vendors now build against. The headline change is structural rather than cosmetic: the protocol is being reshaped around how it actually gets deployed in production, not how it started life as a local, stateful handshake. For anyone running an MCP server, that is a real migration, not a version bump you can ignore.

Sessions are gone, and that is the point

Earlier MCP required an initialize handshake and, over HTTP, a session ID (the Mcp-Session-Id header) that pinned a client to one server instance for the life of the connection. The 2026-07-28 revision removes both. There are no protocol-level sessions, and the initialize handshake is gone. Every request now carries its own protocol version and client capabilities in a _meta field, and a new required server/discover call lets a client ask a server what it supports before doing anything else. Servers that genuinely need state between calls now mint explicit handles and pass them back as ordinary tool arguments, so the state is visible in the request rather than hidden in the transport. The old pattern where a server reached back to the client mid-call for input is replaced by a retry model: the server returns an “input required” result, and the client re-issues the request with the answer attached.

The reason this matters is deployment. A session-pinned protocol needs sticky routing or a shared session store to run behind a load balancer, which is friction every team hosting an MCP server has hit. WorkOS, walking through an implementation on the finalized spec, describes the payoff plainly: no sticky routing and no shared session store, so an MCP server can deploy behind an ordinary load balancer like any other stateless HTTP service. Vercel shipped same-day support through its MCP SDK v2 and kept backward compatibility, so clients built for the 2025 protocol keep working over the same connection while new clients get the stateless path.

Authorization moves to OAuth 2.1 resource-server rules

The auth model tightens in the same revision. MCP servers are now treated unambiguously as OAuth 2.1 resource servers, expected to publish Protected Resource Metadata and honor Resource Indicators so a token minted for one server cannot be replayed against another. The spec folds in several smaller hardening steps on top: clients must validate the iss parameter in an authorization response, per RFC 9207, before redeeming a code, and the older Dynamic Client Registration flow is deprecated in favor of Client ID Metadata Documents.

If you bolted a bearer token onto an MCP server and called it secured, that shortcut is now explicitly out of spec. The upside for developers is convergence: MCP auth is lining up with the same OAuth patterns the rest of the ecosystem already uses, which means identity vendors can support it with standard machinery instead of protocol-specific glue. That is largely why an auth-focused company like WorkOS could ship a working AuthKit integration within days of the spec landing.

A deprecation clock starts on three familiar features

Three features that many existing servers rely on are now deprecated: Roots (a way for a server to ask the client which files or directories it may touch), Sampling (a server asking the client’s own model to generate text on its behalf), and Logging (server-emitted log messages routed through the protocol). They keep working during a newly defined twelve-month minimum deprecation window, but new servers should not adopt them. The suggested migrations are concrete: pass files through tool parameters or resource URIs instead of Roots, call an LLM provider’s API directly instead of Sampling, and write to stderr or OpenTelemetry instead of Logging. The legacy HTTP plus SSE transport, already on its way out, is now formally deprecated in favor of Streamable HTTP as well.

None of these vanish overnight, but the countdown is the actionable part. A server built on Roots or Sampling today has a supported window to move, and starting new work on those primitives now just books future migration debt.

What it means for working developers

The reassuring part is that the finalized SDKs absorb most of the transport churn. Build against MCP SDK v2 or the updated handlers and the stateless plumbing is handled for you, which is why WorkOS frames the work as mostly a shift in patterns rather than a rewrite. The work that does not disappear is the deprecations and the auth. Any server leaning on Roots, Sampling, or Logging now has a clock and a migration to plan, and any custom auth needs to line up with OAuth 2.1 resource-server semantics.

The useful signal is that two companies as different as Vercel and WorkOS shipped support within days of finalization. That suggests the spec is stable enough to build on now, not a draft to wait out. The open question is adoption speed on the client side, because a stateless protocol only pays off when the servers and the clients on both ends speak it, and the deprecated features only truly leave when hosts stop depending on them. Over the next quarter the signals worth watching are how quickly the major MCP clients, from Claude Code and Cursor to the OpenAI and Google integrations, move to the new discovery and auth flows, and whether the twelve-month deprecation windows hold or slip. Stackmaven will check back on or around November 1.

Sources cited

1. Model Context Protocol: 2026-07-28 specification changelog modelcontextprotocol.io
2. Model Context Protocol blog: the 2026-07-28 release blog.modelcontextprotocol.io
3. WorkOS: How to build an MCP app on the 2026-07-28 spec with AuthKit workos.com
4. Vercel changelog: Vercel MCP now supports the 2026-07-28 MCP specification vercel.com