MCP goes stateless: Azure MCP server migration checklist

On 21 May 2026, the Model Context Protocol project locked the release candidate for its next specification version, opening a ten-week validation window ahead of final publication on 28 July 2026. It is the most consequential MCP revision since streamable HTTP arrived. The initialize handshake and the Mcp-Session-Id header are gone, and the protocol core is now stateless. Tasks and the new MCP Apps land as formal Extensions. Six SEPs harden authorization around OAuth 2.0 and OpenID Connect. Three familiar features (Roots, Sampling and Logging) enter a 12-month deprecation window. If your team runs MCP servers on Azure Container Apps, AKS or App Service behind Azure API Management, as most Swedish enterprises building agents on Azure, Copilot Studio or Claude now do, this release changes how you run and secure those servers. Almost every change makes life on Azure easier, provided you start the migration during the validation window rather than after the final ships.

What actually changed in the release candidate

The stateless core: no more handshake, no more session header

The headline change is architectural. The initialize/initialized handshake is eliminated, and with it the Mcp-Session-Id header and protocol-level sessions. In the RC's own words, the protocol version, client info and client capabilities "that used to be exchanged once at connection time now travel in _meta on every request." Every request is now self-contained; capability negotiation happens per request.

Why does this matter operationally? Because the old model forced remote MCP servers into stateful deployment patterns. A server that established capabilities at connection time and stored them against a session ID needed that session to land on the same replica every time. That meant sticky sessions, a shared session store (typically Redis on Azure), or gateway logic that inspected request bodies to route correctly. The RC blog post puts it plainly: a remote MCP server "that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer."

Two new HTTP headers, Mcp-Method and Mcp-Name (SEP-2243), carry the operation being invoked at the transport level, so "load balancers, gateways, and rate-limiters can route on the operation without inspecting the body." For Azure API Management users this is significant: you can now write routing, throttling and caching policies keyed on a header instead of parsing JSON-RPC bodies in policy expressions.

POST /mcp HTTP/1.1
Host: mcp.example.com
Mcp-Method: tools/call
Mcp-Name: query_invoices
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "query_invoices",
    "arguments": { "customer": "..." },
    "_meta": {
      "protocolVersion": "...",
      "clientInfo": { "name": "example-host", "version": "1.4.0" }
    }
  }
}

The exact shape of the _meta payload is defined in the RC schema; the point is that everything a server needs to handle the request arrives with the request. No replica needs to remember anything about the client between calls.

Extensions become first-class

The RC formalises an Extensions framework (SEP-2133). Extensions are identified by reverse-DNS IDs and negotiated through an extensions map on client and server capabilities. They live in their own ext-* repositories with delegated maintainers and version independently of the specification. This is the mechanism that lets the core spec stay small and stable while specialised functionality (long-running tasks, UI rendering, whatever comes next) evolves at its own pace. Extensions are always opt-in and require explicit support from both client and server.

Tasks: long-running work, redesigned for statelessness

Tasks move from experimental core feature to a formal extension, with a lifecycle redesigned to work without sessions. A server can answer a tools/call with a task handle, and the client drives the task with tasks/get, tasks/update and tasks/cancel. Notably, tasks/list is removed: the maintainers concluded it "can't be scoped safely without sessions." If your architecture assumed a client could enumerate its outstanding tasks, you now need to persist task handles client-side.

For Azure teams this maps naturally onto durable back-ends: the task handle becomes a key into whatever you already use for asynchronous work: a Service Bus correlation ID, a Durable Functions instance ID, a row in Cosmos DB. The extension standardises the polling surface; the durability layer remains your choice.

MCP Apps: server-rendered UI in a sandboxed iframe

MCP Apps (SEP-1865) is the second official extension: servers can ship interactive HTML interfaces (charts, forms, video players) that hosts render in a sandboxed iframe inline in the conversation. The security design does real work here: tools declare their UI templates ahead of time, so hosts can prefetch, cache and security-review the templates before anything runs. If you have been generating ad-hoc HTML in tool results and hoping the host renders it, this is the sanctioned replacement — with an actual review surface for your security team.

Authorization hardening: six SEPs and what they mean for Entra ID

The RC lands six SEPs that tighten MCP's alignment with OAuth 2.0 and OpenID Connect:

• SEP-2468: clients must validate the iss parameter in authorization responses per RFC 9207. The maintainers call this "a low-cost mitigation for a class of mix-up attack that is more prevalent in MCP's single-client, many-server deployment pattern", meaning one client talking to many servers, each potentially pointing at a different authorization server.
• SEP-837: clients declare an OpenID Connect application_type during Dynamic Client Registration.
• SEP-2352: credentials are bound to the issuing authorization server's issuer, so a token from one AS cannot be replayed against another.
• SEP-2207: documents how to request refresh tokens from OpenID Connect servers.
• SEP-2350: clarifies scope accumulation during step-up authorization.
• SEP-2351: clarifies the .well-known discovery suffix.

If you protect MCP servers with Microsoft Entra ID, put two items on your review list now. First, verify how your token flows behave under issuer binding and iss validation — multi-tenant Entra apps, where the issuer varies per tenant, deserve particular attention. Second, note that several SEPs assume Dynamic Client Registration; Entra ID's support for RFC 7591-style DCR has historically been limited, so many Azure deployments pre-register clients instead. That pattern remains workable, but check what the MCP client implementations you depend on (Copilot Studio, Claude, custom hosts) expect from your authorization server once they adopt the RC behaviour.

The deprecation policy: Roots, Sampling and Logging are on the clock

The RC introduces a formal deprecation lifecycle (SEP-2577) and immediately applies it to three features. These are annotation-only deprecations: the methods, types and capability flags continue to work in this release and in every specification version published within a year of it. Nothing breaks on 28 July, but the direction of travel is explicit.

• Roots: replaced by tool parameters, resource URIs, or server configuration.
• Sampling: replaced by direct integration with LLM provider APIs. If your server asked the client's model to do work on its behalf, call your model provider (Azure OpenAI, Anthropic, or otherwise) directly instead.
• Logging: replaced by stderr for stdio servers and OpenTelemetry for structured observability. For Azure teams this is a gift: OpenTelemetry flows straight into Application Insights, which is where your MCP server telemetry should have been all along.

What statelessness means on Azure specifically

The stateless core removes the awkward parts of running MCP servers on Azure's managed compute:

• Azure Container Apps: you can switch session affinity off, scale on plain HTTP concurrency, and use scale-to-zero without worrying about severing live sessions. Every replica can serve every request.
• AKS: drop the sessionAffinity and cookie-based sticky-session annotations from your Services and ingress. Rolling deployments stop disrupting long-lived MCP connections because there are no long-lived MCP connections to disrupt at the protocol level.
• Azure API Management: route, throttle and cache on the Mcp-Method and Mcp-Name headers instead of parsing JSON-RPC bodies. A rate limit per tool name becomes a one-line policy condition on a header.
• Redis session stores: if you deployed Azure Cache for Redis purely to share Mcp-Session-Id state across replicas, that line item can come out of your bill once you complete the migration.

There is a cost to weigh: per-request _meta adds a few hundred bytes of overhead to every call, and anything you previously computed once at initialize time (capability intersection, feature flags) now happens per request. For most servers this is negligible; for very chatty servers behind APIM it is worth a quick look at request sizes and any body-size-based pricing or limits in your gateway tier.

Migration checklist for the validation window

• 1. Inventory your MCP surface. List every MCP server you run (remote and stdio), every host that connects to them, and which SDK version each is on. Flag anything using Roots, Sampling, Logging, or the experimental Tasks feature.
• 2. Find your session-state dependencies. Grep for Mcp-Session-Id handling, initialize-time capability caching, and any per-session storage. Each one is a migration task.
• 3. Upgrade SDKs against the RC. Track your SDK's RC branch and run your integration tests against it in a non-production environment during the window. File issues now. That is what the window is for.
• 4. Simplify your Azure deployment. Once your server is stateless: disable session affinity in Container Apps, remove sticky-session ingress annotations in AKS, and plan the decommissioning of any Redis session store.
• 5. Rework gateway policies. Rebuild APIM policies around the Mcp-Method and Mcp-Name headers. This is also the moment to add per-tool rate limits you could not easily express before.
• 6. Review authorization flows. Walk through the six auth SEPs against your Entra ID app registrations: iss validation, issuer binding, application_type, refresh-token behaviour, scope step-up and discovery endpoints.
• 7. Migrate off deprecated features. Move Sampling calls to direct model-provider APIs, replace Roots with explicit tool parameters or configuration, and route logs through OpenTelemetry into Application Insights. You have 12 months, but the work is easiest bundled with the SDK upgrade.
• 8. Adopt Tasks and MCP Apps deliberately. If you have long-running tools, plan the move to the Tasks extension, and design client-side persistence for task handles, since tasks/list is gone. Evaluate MCP Apps only with a security review of the pre-declared template model.

The Swedish and EU angle

For Swedish and EU organisations there are three practical implications beyond the engineering work.

Data residency gets simpler to argue. A protocol-level session store is state, and state has a location. When session context lived in Redis or in replica memory, your data-flow documentation had to account for it: what is in the session, where the cache runs, how long entries live. A stateless MCP core removes that component from the diagram entirely. Requests carry their own context, are processed, and are gone. For teams answering GDPR Article 30 records or Schrems-era transfer questionnaires, one fewer stateful component in the pipeline is a genuine simplification, though your tools' downstream data flows are unchanged.

Security hardening aligns with NIS2-era expectations. Swedish enterprises in scope of NIS2 are being pushed towards demonstrable, standards-based access control. An MCP stack that validates issuers per RFC 9207, binds credentials to their issuing authorization server, and runs behind centrally-policed gateway rules is much easier to defend in a security audit than the looser OAuth wiring many early MCP deployments shipped with. If you are documenting agent security controls for an internal risk function, the six auth SEPs give you concrete, citable requirements to build against.

Procurement and lifecycle planning get firmer ground. Public-sector and regulated buyers in Sweden routinely ask vendors about the stability and support horizon of the protocols their solutions depend on. MCP now has a formal deprecation policy with a minimum 12-month window and an extensions model that keeps the core small. That is exactly the kind of governance signal that makes it easier to standardise on MCP in an upphandling context: you can now answer "what happens when the protocol changes?" with a documented policy rather than a shrug.

Conclusion

The 2026-07-28 release candidate is that rare specification revision where the protocol gets simpler and your infrastructure gets simpler at the same time. Stateless requests run behind ordinary load balancers and remove one stateful component from your compliance story. The Extensions framework gives Tasks and MCP Apps room to grow without bloating the core, and the authorization SEPs close real gaps in multi-server OAuth flows. The ten-week validation window is the cheapest migration insurance you will get this year. Spend a sprint of it on the checklist above and 28 July becomes a non-event.

Sources

• MCP blog: The 2026-07-28 specification release candidate
• Model Context Protocol specification, 2026-07-28 version