Announcing v2.0 of the official MCP C# SDK - .NET Blog

The Model Context Protocol (MCP) C# SDK has reached v2.0, implementing the 2026-07-28 revision of the MCP specification. It’s the largest revision of the protocol since it launched.
This release is different from the ones that came before it. Earlier updates added capabilities on top of the existing shape of the protocol. The 2026-07-28 revision goes back to the foundation and rethinks how MCP works over HTTP. It makes the protocol stateless by default, standardizes the HTTP surface so ordinary HTTP infrastructure can route MCP traffic, and introduces Multi Round-Trip Requests so interactive tools no longer require a long-lived session.
That shift plays directly to .NET’s strengths. MCP over HTTP is a web workload after all, and ASP.NET Core has always focused on the exact concerns this MCP specification revision cares about: routing, middleware, headers, load balancing, and horizontal scale. The MCP C# SDK builds right on top of ASP.NET Core, so much of what the new spec asks for is already second nature in .NET.
And before we go any further, here’s the reassurance up front: v2.0 is backward compatible. Upgrading the SDK doesn’t force you off the clients and servers you already have, and your stable v1 code keeps compiling and running. We’ll come back to that promise in depth, but hold onto it while we tour what’s new.
The whole revision, in one place
Here’s a tour of what’s new.
In the previous spec, calling a tool over Streamable HTTP meant completing the initialize handshake first and, with the v1 SDK defaults, establishing a session. The server returned an Mcp-Session-Id that the client was required to carry on every later request, pinning it to whichever server instance issued it. Horizontal deployments needed sticky routing or session migration to make that work.
The 2026-07-28 revision replaces that connection-scoped setup with self-contained requests: the initialize / initialized handshake is gone (SEP-2575), as is the Mcp-Session-Id header (SEP-2567), and the protocol version and capabilities now travel with each request.
The practical effect is that any server instance can handle any request, so the sticky sessions and shared session stores that horizontal deployments needed are no longer required at the protocol layer. Serverless, multi-instance, and edge deployments simply work.
The SDK moves in lockstep with the spec: the HTTP server transport now runs statelessly by default. Where v1 configured stateful sessions out of the box, in v2 HttpServerTransportOptions.Stateless defaults to true.
That’s the whole server. Drop it behind a round-robin load balancer, scale it to as many instances as you like, and there’s nothing to synchronize between them. It containerizes cleanly, too: a stateless MCP server is an ordinary ASP.NET Core app, so the usual multi-stage Dockerfile on .NET is all you need to ship it anywhere containers run.
“Stateless protocol” doesn’t mean “stateless application.” If your server needs to carry state across calls, do what HTTP APIs have always done: mint an explicit handle from one tool (a basketId, a browserId) and have the model pass it back as an ordinary argument on later calls. It turns out the model threading an identifier from one call to the next is often more powerful than session state hidden in transport metadata: the model can compose handles across tools, reason about them, and hand them off between steps.
Opting into sessions
There’s a subtler reason stateless is the default, and it’s about looking forward, not just scaling out. Because the 2026-07-28 wire format drops the initialize handshake and Mcp-Session-Id entirely, running with Stateless = true is the forward-compatible choice: it’s the configuration that lets your server answer 2026-07-28 clients directly, natively speaking the new protocol. Older clients aren’t left behind (the server still falls back to the legacy handshake for them), but new clients get the modern path with nothing in the way.
Going stateless changes the shape of an MCP request: it’s now a single, self-describing HTTP POST. That opens a door we couldn’t walk through before: your existing HTTP infrastructure can finally treat MCP like any other traffic. No sidecar, no body parsing, no special cases.
The 2026-07-28 revision standardizes a small set of HTTP headers that mirror the fields intermediaries actually care about (SEP-2243). A tools/call now travels with Mcp-Method: tools/call and Mcp-Name: get_order_status alongside the JSON-RPC body, so a load balancer, proxy, gateway, WAF, or observability tool can act on MCP traffic without deep packet inspection. And you can promote any tool parameter into an Mcp-Param-* header with a single attribute.
This is exactly what geo-distributed routing needs. Picture a tool that calls a backend service (an orders service, say) deployed across several regions. The tool takes a region and an orderId, and a global load balancer needs to send each call to the co-located regional deployment. Promote region to a header, and the router can dispatch on it directly, without ever reading the request body:
The [McpHeader] attribute annotates the parameter and emits an x-mcp-header keyword into the tool’s input schema, so clients know to lift that argument into a header on the wire. The design goals for standardized headers read like a love letter to anyone who has ever run a service behind a proxy. They were built to:
That third goal matters for correctness. The body is always the source of truth; if a header and the body disagree, the server rejects the request rather than guessing, returning a HeaderMismatch error. The whole feature is additive and non-breaking: clients send the headers on Streamable HTTP, but servers only enforce them once both sides are speaking 2026-07-28, so nothing you have today breaks.
This is the kind of feature that only looks obvious in hindsight, and it’s a perfect fit for ASP.NET Core, where headers, routing, and middleware are the native vocabulary. It’s