Remote MCP Server Goes Stateless: What the New Spec Changes

Microsoft's MCP C# SDK hit version 2.3 this month, and InfoQ's write-up on October 26 is a good reminder of how much changed under the hood. Every Tier-1 SDK now targets the 2026-07-28 Model Context Protocol spec, which drops sessions from the protocol core. If you run a remote MCP server, or plan to, that's the biggest deployment change since MCP launched.

Here's why it matters. A year ago, putting an MCP server behind a normal load balancer meant sticky routing, a Redis session store, or random "Session Not Found" errors. The new spec makes each request self-contained. That moves MCP from "special snowflake service" to "boring HTTP API," and boring is exactly what you want in production.

TL;DR#

• The 2026-07-28 MCP specification removes the initialize handshake and the Mcp-Session-Id header, so any server instance can answer any request.
• New routing headers, cache hints and Multi Round-Trip Requests let gateways, load balancers and serverless platforms handle MCP traffic like ordinary HTTP.
• If you built an MCP server that leans on sessions, elicitation or the old SSE transport, plan a migration now. Deprecated features keep working for at least 12 months.

What changed in the MCP specification#

The official release post describes the shift plainly: MCP moves from a bidirectional, stateful protocol to a request/response core. Instead of negotiating a session once, every request now carries its protocol version, client identity and capabilities in a _meta field.

A few other changes ride along with that:

• server/discover: an optional call that lets a client ask what a server supports before using it.
• Routing headers: Streamable HTTP requests must include Mcp-Method and Mcp-Name, mirroring the JSON-RPC body. If they disagree with the body, the request is rejected.
• Cache hints: tools/list, resources/list and similar responses carry ttlMs and cacheScope, and list order is now deterministic.
• Multi Round-Trip Requests (MRTR): when a tool needs input mid-call, the server returns an "input required" result instead of holding a stream open. The client answers and retries.
• Tasks as an extension: long-running work moves into a poll-based tasks extension.

Roots, Sampling, Logging and the legacy HTTP+SSE transport are deprecated, with a formal policy guaranteeing at least twelve months before removal.

Why a remote MCP server needed this#

Local MCP servers, the kind that run on a developer's laptop over stdio, never cared about sessions. Remote ones did, a lot.

Google's engineering post on the update spells out the old pain. Sessions pinned a client to one pod. Round-robin load balancers sent follow-up requests to a different pod, which returned HTTP 400 "Session Not Found." Teams patched around it with sticky routing or a shared Redis session store. Every rollout or autoscale event risked dropping live sessions.

That's a lot of infrastructure just to let an AI assistant call get_invoice.

With the stateless core, Google notes that MCP servers can run on Cloud Run or Cloud Functions behind standard load balancing, and that the GitHub MCP Server removed its Redis session storage. Restarts and deploys are meant to be invisible to clients.

Technical breakdown: what the new request flow looks like#

Here's the difference in one picture:

OLD (stateful)
client -> initialize -> pod A        (session 123 lives here)
client -> tools/call -> LB -> pod B  => 400 Session Not Found
fix: sticky routing or a Redis session store

NEW (2026-07-28)
client -> tools/call + _meta + Mcp-Method/Mcp-Name -> LB -> any pod
gateway routes, meters and audits from headers alone

State didn't disappear, it moved#

Microsoft's v2.0 announcement makes a point worth repeating: a stateless protocol isn't a stateless application. If your tool builds a draft order across several calls, return an explicit handle (a basket ID, a draft ID) and have the model pass it back. Store the real state in your database, where it belongs anyway.

Trade-offs to know about#

MRTR is the part that takes real work. Code that called elicitation or sampling from inside a tool has to be restructured, and in the C# SDK those calls throw in stateless mode. InfoQ also flags a source-breaking change in 2.3 and a timeout gotcha for handlers that run silently for a long time.

What it means for businesses running AI on their own systems#

If you're a CTO or an operations lead, here's how I'd read this.

Building a custom MCP server just got cheaper to run. You don't need special infrastructure. A remote MCP server that exposes your order system or CRM can sit behind the gateway and auth you already have.

Gateways get smarter for free. Because the method and tool name now travel in headers, an API gateway can rate-limit refund_order differently from list_orders without parsing JSON. That's a cheap, real control for agents touching money or customer data.

Auth got stricter. The spec tightens OAuth: clients must validate the issuer (RFC 9207), credentials are bound to the issuer that minted them, and Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents. Good for security, but older clients may need updates.

Vendor servers will change under you. Expect version bumps from third-party MCP servers over the next year, and test them in staging first.

How to act on it: a migration checklist#

1. Inventory your MCP servers. List each one, its transport (stdio, Streamable HTTP, legacy SSE) and its SDK version.
2. Find session dependencies. Search for Mcp-Session-Id, in-memory per-session caches and anything that assumes the same pod handles a follow-up call.
3. Move state into handles. Replace session state with explicit IDs that tools return and accept, backed by your database.
4. Rewrite mid-call prompts as MRTR. Any tool that asks the user a question or requests sampling needs the input-required pattern.
5. Pick a durable task store. If you use long-running tasks, the in-memory stores are for development only. Use Postgres, Redis or similar.
6. Upgrade the SDK and test both protocol versions. The C# SDK 2.2 lets older and newer clients share one endpoint, which helps during rollout.
7. Add header-based policies at the gateway. Rate limits, audit logs and approval rules per tool name.
8. Retire SSE on your own schedule. You have at least a year, so don't wait until month eleven.

How MagicMakers Lab approaches this#

When we build MCP servers for clients, we treat them like any other production API: stateless where possible, state in the database, auth and rate limits at the edge, and human approval gates on tools that move money or change records. The new spec lines up with that approach, so migrations are usually about restructuring a handful of tools rather than rebuilding. It's the same thinking behind the order pipeline we built for Framico, where 200+ orders a day ship with zero manual steps. If you want a remote MCP server that connects agents to your existing stack, our MCP development work starts with exactly this kind of audit.

Key takeaways#

• The 2026-07-28 spec makes the MCP core stateless, so remote servers can run behind ordinary load balancers and on serverless.
• Application state still exists. Pass it as explicit handles and keep it in your database.
• Routing headers let your gateway apply per-tool rate limits and audit logs without reading request bodies.
• Elicitation, sampling and session-based code need the most migration work, and SSE is on a 12-month offramp.
• Test vendor MCP servers and your own in staging before upgrading production agents.

FAQ#

What is a remote MCP server?#

A remote MCP server is a Model Context Protocol server that runs on a network host instead of on the user's machine. AI clients reach it over HTTP, usually with OAuth. It lets assistants and agents call your tools and read your data from anywhere, which makes it the normal choice for business systems shared across a team.

Is MCP stateless now?#

The protocol core is, as of the 2026-07-28 specification. The initialize handshake and session ID header are gone, and each request carries its own version and capabilities. Your application can still keep state, but it should pass explicit handles like an order ID back and forth rather than relying on a protocol session.

Do I have to migrate my MCP server right away?#

No. Deprecated features keep working for at least twelve months under the new policy, and SDKs like the C# 2.x line keep stable 1.x APIs running. You should plan the work now, though, especially if your server uses session IDs, server-initiated elicitation or the legacy SSE transport.

What is the difference between a local and a remote MCP server?#

A local MCP server runs on the same computer as the AI client, usually over stdio, and only that user can reach it. A remote server runs on shared infrastructure over HTTP, supports many users, and needs proper authentication, rate limits and monitoring. Most business integrations end up remote.

Want to know if your MCP servers, and the agents that depend on them, are ready for the new spec? We'll look at your setup, flag what needs to change and give you a plain migration plan. Book a free audit.

Sources#

• MCP C# SDK 2.0 Makes HTTP Stateless by Default and Adds Multi Round-Trip Requests (InfoQ)
• The 2026-07-28 Specification (Model Context Protocol blog)
• Scaling AI Agent Infrastructure with the MCP Stateless updates (Google Developers Blog)
• Announcing v2.0 of the official MCP C# SDK (Microsoft .NET Blog)