A platform engineer I read about spent a Friday afternoon debugging why agents were hitting the wrong MCP server instance after a routine rolling restart. The culprit was Mcp-Session-Id, pinning clients to one server process and turning a standard deploy into a coordination problem. That problem is now gone - by spec.
On September 28, 2026, the Agentic AI Foundation (a Linux Foundation directed fund) finalized what its own co-creator described as the biggest release in MCP's history. The update shipped finalized stateless architecture, hardened OAuth authorization, a formal 12-month deprecation policy, and MCP Apps plus MCP Tasks graduated to official extensions - with co-creator David Soria Parra saying "some people jokingly call it a v2, and I think in spirit that's accurate."
This is the post for the team that already knows the session handshake is gone (that shipped July 28) and wants to understand what the September finalization actually adds - and what it quietly takes away.
What "stateless MCP" actually means for your infrastructure
The session handshake is gone, and that one change restructures how you run MCP servers in production.
The 2026-07-28 specification removes the stateful handshake and session management - the initialize/initialized handshake is gone, and so is the protocol-level session. Client information, protocol version, and capabilities now travel in a request's _meta field on every call, making each request self-describing.
The infrastructure consequence is direct: remote servers can run behind standard round-robin load balancers without session affinity or synchronization. Any instance can answer any request without first replaying a handshake or looking up shared session state.
For most teams, the before/after looks like this:
| Concern | Before (2025-11-25) | After (2026-07-28, crowned Sept 28) |
|---|---|---|
| Load balancer type | Sticky session or Redis-backed gateway | Plain round-robin; no MCP-specific routing |
| Rolling restart | Clients re-handshake; brief disruption | Restarts invisible to clients |
| Tool list caching | Re-negotiated per session | Cacheable with TTL; serveable from CDN |
| Auth model | Bring-your-own-token tolerated | Formal OAuth 2.1 resource server, issuer validation mandatory |
| Routing header | None; body parse required | Mcp-Method + Mcp-Name headers allow header-based routing |
The enterprise release is secretly a self-hosting release. An MCP server is now an ordinary HTTP service, and serving one on hardware you own just got radically simpler.
The auth changes are bigger than "hardened OAuth"
Enterprise Managed Authorization, built with Okta, means a corporate IdP becomes the authoritative gatekeeper for MCP server access - corporate credentials, not personal ones. That sentence sounds bureaucratic, but it closes the most common enterprise deployment objection: the standard per-user OAuth flow forced every employee to authorize each MCP server individually, which broke centralized onboarding and made access audits painful.
The release adds six authorization enhancements that tighten how MCP uses OAuth and OpenID Connect: issuer validation per RFC 9207, tokens bound to the authorization server that issued them, a documented OIDC refresh-token flow, and clearer scope-accumulation rules for step-up auth, among others.
The issuer validation piece is the one to act on first.
Mandatory validation of the OAuth iss parameter closes an entire class of mix-up attacks - and the MCP team's own Den Delimarsky was explicit that this is "preventive engineering, not incident response" with no known exploitation at the time of release.
A tool like Beagle, which reads Slack context and drafts replies for human approval, sits downstream of exactly this auth surface - the agent needs scoped read access to channels and the ability to post-pending-approval, and EMA means that access can now be provisioned and revoked centrally by an IT admin rather than per-seat by each user.
Beagle in action#platform-eng, 10:02am_meta field docsWhat the spec quietly removes - and what that costs you
Three features shipped to deprecation with a 12-month window: Roots, Sampling, Logging, and the legacy HTTP+SSE transport are deprecated.
Roots and Sampling are the ones that sting. Roots let a client advertise filesystem paths to a server; the replacement is to pass paths as tool parameters or server config instead. Sampling - where a server could request LLM completions from the client - is gone entirely; servers should now call LLM APIs directly.
The logging deprecation has a specific replacement. Use stderr for stdio servers, or structured OpenTelemetry for anything real. If you have built monitoring dashboards against MCP's built-in log events, you have 12 months to migrate those to OTEL traces.
The stateless model also introduces one honest trade-off the announcement underplays:
bigger payloads, since state now rides the wire - and out-of-band server logging is gone in the stateless model.
Every request carries client identity and capabilities in its _meta field, which adds bytes. For a high-volume fleet processing thousands of tool calls per minute, that overhead is worth benchmarking before you migrate.
The scale numbers the spec now makes possible
By mid-2026, more than 10,000 MCP servers had reportedly been deployed in production, with the protocol's SDKs downloaded over 97 million times per month. The session-affinity model was the ceiling on how large those deployments could grow without custom infrastructure.
With stateless architecture, an MCP client can speak to a load balancer that connects with any server - tens of thousands of agents per deployment are now architecturally possible. That is not a marketing claim about the future; it is a description of what horizontal pod autoscaling on a plain Kubernetes deployment now looks like for an MCP server, which previously required either sticky sessions or a shared Redis store for session state.
The SDK support landed alongside the spec: TypeScript, Python, Go, and C# SDKs already support the new version; Rust is in beta.
MCP stateless upgrade: common questions
What changed in the September 28 MCP release?
The September 28, 2026 release from the Agentic AI Foundation finalized stateless architecture, hardened OAuth authorization, a 12-month formal deprecation policy, and graduated MCP Apps and MCP Tasks to official extensions. The July 28 spec did the technical work; September crowned it as the enterprise-stable version and added the Enterprise Managed Authorization extension.
Do I need to update my MCP server after the stateless spec?
Yes, but you have time. The handshake removal is the breaking change:
the new protocol removes the required handshake, the Mcp-Session-Id header, and protocol sessions from the core request path - each request now carries the protocol version, client identity, and client capabilities it needs.
Servers written against the 2025-11-25 spec continue to work through the deprecation window, but new clients will not send a handshake.
What is Enterprise Managed Authorization in MCP?
Enterprise Managed Authorization is a new extension that lets an IT administrator centrally provision MCP server access through a corporate identity provider like Okta or Microsoft Entra ID. The Okta Managed MCP Server acts as a native bridge that translates natural language prompts into structured, auditable actions while strictly enforcing existing OAuth scopes and least-privilege boundaries. The result is that access grants and revocations flow through the same IdP controls as any other enterprise SaaS tool.
What MCP features are being deprecated?
The stateless update introduces Multi Round-Trip Requests for interactive approval flows, MCP Apps for embedding HTML interfaces in conversations, and a Tasks extension for long-running background work - while Roots, Sampling, Logging, and the legacy HTTP+SSE transport are deprecated with a 12-month window.
Does stateless MCP increase payload size?
Yes, by design. State that previously lived in a server-side session now travels inline on every request in the _meta field.
Protocol version, client info, and capabilities now travel inline in a _meta field on each request
rather than once at connection setup. The trade-off is horizontal scale and simpler infrastructure; the cost is measurable in bytes per request, so benchmark under your actual call volume before committing to the migration.