Stateless MCP in production: running old and new protocol versions side by side

Two and a half months after the Model Context Protocol published its stateless 2026-07-28 revision, large vendors are shipping production software that speaks it. Microsoft released Azure MCP Server 3.0 on 12 October, and on 16 October Red Hat made its MCP gateway generally available in Connectivity Link 1.5. Neither switched to the new version outright. Both run old and new side by side, and their release notes show what that means in practice for anyone operating MCP servers: which clients must change, which features don't yet work statelessly, and what a gateway should log.

The protocol change, briefly

The 2026-07-28 changelog removes the session handshake. Every request carries its own protocol version and client capabilities, servers must implement a server/discover call that advertises the versions they support, and a mismatch returns an UnsupportedProtocolVersionError. Streamable HTTP POST requests must carry Mcp-Method and Mcp-Name headers, and a HeaderMismatchError covers headers that disagree with the body. Change notifications move to a single opt-in subscriptions/listen stream. The background is in the earlier explainer on the stateless specification.

Azure MCP Server 3.0: new by default, old still accepted

Microsoft's upgrade notes say the server "uses the stateless MCP protocol 2026-07-28". Clients on that version "must send Mcp-Method and Mcp-Name headers on every POST", while clients on 2025-11-25 keep "automatically negotiated backward compatibility". Microsoft files this under "Check custom HTTP clients": the risk is highest for scripts and in-house clients that build requests themselves.

The rest of the upgrade list is a reminder that a major MCP server release changes more than the transport:

• Tool names change. Preview users must rename resilience_* tools to resiliency_* "in filters and allowlists". Any policy that allows or denies tools by name needs updating with the server.
• Inputs get stricter. Unknown parameters now produce errors, and obsolete parameters must be removed from saved calls, scripts and prompts.
• Responses change shape. Several tools now wrap results differently, so parsers and test fixtures need updating.
• Destructive tools are labelled as such. The MySQL and PostgreSQL query tools are "destructive, non-idempotent, and non-read-only", and SQL-verb filtering was removed. What a query can do now depends on the signed-in database permissions, so Microsoft's advice is least-privilege database accounts.

Microsoft's walkthrough starts in --read-only mode, advises a development subscription, and notes that "a natural-language prompt isn't a substitute for access controls".

Red Hat's gateway: two versions on one endpoint

Red Hat's gateway sits in front of many MCP servers. It now supports the three 2025 protocol versions (2025-03-26, 2025-06-18 and 2025-11-25) and 2026-07-28 "simultaneously on a single endpoint". Clients negotiate the version and the gateway routes accordingly, so older servers keep working next to newer ones. The /mcp path auto-negotiates; a separate /mcp/stateful path forces the older protocol.

The release is candid about what the stateless path can't do yet. Progressive tool discovery, which lets an agent browse a large catalogue with discover_tools and then narrow its working set with select_tools, "relies on sessions and state" and is available only on the stateful protocol for now. Resource federation also works "primarily on the stateful path". Teams with hundreds of tools behind a gateway, where sending every tool definition wastes the model's context, may find the older protocol still does more for them.

The rest of the release is about operating MCP as shared infrastructure:

• Audit entries per tool call. The router logs each valid tools/call with the calling user (the token's sub claim, if available), the tool and server, the response status and request and session identifiers. It logs calls it rejects early too.
• Metrics per upstream server. Five Prometheus metrics cover discovery attempts and duration, tool counts, connection failures and the size of each server's tools/list response.
• Content checks. An integration with NeMo Guardrails screens tools/call requests before they reach a server and responses before they return.
• Isolation. Teams can get separate gateway instances, or a shared gateway with separate endpoints per team.

The console plug-in that manages gateways from the OpenShift console is a developer preview, not part of the GA scope.

The reference servers reached 1.0

The official reference servers also hit a milestone. On 11 October the servers repository released v1.0.0 of the filesystem, memory, everything and sequential-thinking packages on npm, with new releases of the fetch, git and time servers on PyPI. The release notes tie it to the SDK 1.x release branch and don't describe it as a move to the new protocol revision. One change is worth noting for anyone who runs the fetch server: it now refuses private, loopback and metadata addresses by default, a guard against the server-side request forgery seen in many MCP advisories.

What is new, and what still needs work

Mixed versions are the normal state for a while. Both vendors chose negotiation over a cut-over. Expect clients, servers and gateways at different revisions for months, and test each combination you depend on.

Stateless isn't a free upgrade. Features built on sessions, such as Red Hat's progressive discovery, need redesign before they work on the new revision. A gateway that offers both paths lets you move servers one at a time, but it also means two code paths to secure and monitor.

Headers help only if they are checked. Mcp-Method and Mcp-Name let a gateway route and meter without parsing bodies. A gateway that authorises on them should also confirm they match the body, which is what the specification's HeaderMismatchError is for.

Identity in the audit log is the part that matters most. Red Hat logs the token's subject "if available". A log of tool calls without a person attached answers what happened but not who did it. Make sure your MCP traffic carries per-user identity before you rely on the logs.

What it means for engineering and security leaders

MCP is moving from per-developer configuration to shared, centrally run infrastructure, with the versioning, logging and change control that implies. The first production releases on the new revision handle the transition by supporting both versions, and they still have gaps on the stateless side. Plan for a staged migration, not a switch.

Practical takeaways

• List the MCP servers and clients you run, with the protocol revision each supports. Custom HTTP clients are the most likely to break.
• Before upgrading a shared MCP server, read its tool renames and response changes, and update allowlists, saved prompts and parsers in the same change.
• If you depend on progressive tool discovery or other session features, keep a stateful path available until your gateway supports them statelessly.
• At the gateway, route on Mcp-Method and Mcp-Name, and reject requests whose headers don't match the body.
• Log every tool call with the user, tool, server and outcome, and check that the user field is actually filled.
• Start new servers read-only, with least-privilege credentials, and treat any tool labelled destructive as needing approval.
• If you run the reference fetch server, upgrade so that private and metadata addresses are refused by default.