MCP C# SDK 2.0 Goes Stateless, Adds Multi Round-Trip Tool Calls

What shipped

The official Model Context Protocol SDK for .NET has reached version 2.0. The release implements the 2026-07-28 revision of the MCP specification, and the SDK team describes that revision as rebuilding how the protocol runs over HTTP rather than adding features on top of the old design.1 Three changes stand out. HTTP servers no longer keep sessions by default. Tool calls now carry standard headers that ordinary infrastructure can route on. And a new mechanism called Multi Round-Trip Requests (MRTR) lets tools ask for input partway through a call without holding a connection open.14

Microsoft announced 2.0 on July 28, the day the specification became final.15 The release is in the news again because the SDK has since moved through versions 2.1, 2.2 and 2.3. Those updates added hybrid session serving, an opt-in subscriptions/listen handler, and fixes for discovery, OAuth and shutdown.4 Release dates and version numbers match across every outlet that covered the SDK. The spread of release dates is the main sign that people are now upgrading production servers, not just reading about the change.

The end of the session

Under the previous specification, a client calling a tool over Streamable HTTP first had to complete an initialize handshake. With version 1 defaults, it also had to keep an Mcp-Session-Id header that tied it to one server instance. Teams running several instances needed sticky routing or session migration to make that work.1 The new revision removes both the handshake (SEP-2575) and the session header (SEP-2567). Each request now carries its own protocol version and capabilities, so any instance can answer any call.122

In the SDK, HttpServerTransportOptions.Stateless now defaults to true, where version 1 set up stateful sessions automatically.15 Sessions are still available: servers that need unsolicited server-to-client messages can set the flag to false. The legacy SSE endpoints and stateful-only options now trigger compiler warnings MCP9004 and MCP9006.14 Clients call a new server/discover method first and fall back to the old handshake when talking to older servers.43

Coverage agrees on one point: a stateless protocol does not force a stateless application. The SDK team and the specification maintainers both recommend that servers needing continuity return an explicit handle, such as a basket ID, from one tool. The model then passes it back as an ordinary argument.125 The maintainers argue this works better than session state hidden in the transport, because the model can see the handle and use it across tools.25 For enterprise teams, this moves state out of the protocol and into the application's own design, where existing database and caching patterns already apply.7

MCP traffic becomes ordinary HTTP traffic

Each tools/call now arrives with Mcp-Method and Mcp-Name headers alongside the JSON-RPC body. Load balancers, gateways, web application firewalls and observability tools can therefore act on MCP traffic without opening the payload.1 The .NET SDK adds an [McpHeader] attribute that copies a tool parameter into an Mcp-Param-* header. The body remains the authoritative copy: if a header disagrees with it, the server returns a HeaderMismatch error.4

This is the change most relevant to enterprise operations. The specification blog quotes platform vendors on the point. Cloudflare supported the spec from day one, and an unnamed implementer said removing sessions makes MCP workable at enterprise scale.21 Cloudflare later said it no longer needs a Durable Object just to speak the protocol, so MCP servers can run in a plain Worker.24 A Microsoft App Service post makes a similar case. The stateless pattern its earlier guidance had to add by hand is now how the protocol works, so scaling an MCP server looks more like scaling a normal web app.29

Multi Round-Trip Requests: interactivity without a channel

Removing sessions caused a real problem. Features like elicitation, which asks the user to confirm something or supply a missing value, depended on the server sending requests back to the client over a live session.1 MRTR, defined in SEP-2322 and called the headline feature of the revision, reverses that flow.1 A tool throws InputRequiredException, built with InputRequest.ForElicitation, ForSampling or ForRootsList, and returns it with an opaque requestState token. The client gathers the answers and sends the same call again with inputResponses attached.4 This can repeat over several rounds. Because everything the server needs travels in the payload, no session is required.1

MRTR replaces the earlier server-initiated mechanisms for elicitation, sampling and roots on stateless servers.125 The old APIs, ElicitAsync, SampleAsync and RequestRootsAsync, still work on stateful sessions but throw errors in stateless mode. Sampling, roots and logging APIs now carry MCP9005 deprecation warnings.2 For autonomous agents, this matters more than the scaling changes. An agent that has to ask a person before a costly action, such as a refund, a deletion or a purchase, can now do so in a way that survives load balancing, serverless cold starts and instance restarts.510

On backward compatibility, the SDK handles most cases but not all. When a client using the 2025-11-25 spec or earlier connects over a stateful session, the SDK converts MRTR into the old server-initiated requests. When such a client connects without a session, the input request fails with an McpException.14 Teams with a mix of client versions can use version 2.2's HttpServerSessionMode, which serves both protocol revisions from one endpoint.4

The open question: trusting requestState

This is the clearest gap in the coverage. Independent .NET writer Benjamin Abt says to treat requestState as an untrusted continuation token. The client holds it and sends it back, so the server should not trust it just because the server created it.2 InfoQ notes that a reader asked whether the protocol protects the token against tampering or reuse across sessions, and that no reply appeared.4 Another write-up describes the specification as currently having no explicit protocol-level guard against those attacks.3

When the server no longer holds state, the payload has to be protected instead. In practice, servers should sign or encrypt the token and bind it to a user and a time window before relying on it. The SDK team says its next focus is end-to-end authentication and authorization.4 Until that work ships, protecting requestState is each implementer's job.

The MCP and A2A stack

The release fits a broader split in agent infrastructure. Analysts commonly describe MCP as the link between an agent and its tools, and Google's Agent2Agent protocol (A2A) as the link between agents.1113 The Linux Foundation said in April that A2A had more than 150 supporting organizations and was integrated into Google, Microsoft and AWS platforms. Its features include signed Agent Cards that let one agent verify another's identity.12 One enterprise guide sums it up: MCP is how an agent reaches your systems, A2A is how it reaches other agents, and since the July specification MCP runs like any other API tier.17

Some of the figures behind this picture conflict, so specific numbers deserve caution. MCP SDK downloads appear as about 97 million a month in early 2026, more than 110 million, and close to 500 million by July, depending on the source.141917 Accounts also differ on when A2A reached version 1.0 (March or April) and when it moved under the Agentic AI Foundation (mid-2025, or August 17, 2026).1819 One explainer credits Google with leading the stateless work30, but the specification posts list David Soria Parra and Den Delimarsky as lead maintainers.2122 Google's own post calls the revision the biggest change to MCP since launch and pitches it as infrastructure for enterprise AI.23

Why it matters

The direction of the change matters more than any single number. MCP started as a protocol shaped by long-lived local connections, and it now behaves like standard web traffic: stateless requests, routable headers and cacheable results.28 Version 2.0 makes this the default for .NET and ASP.NET Core teams while keeping existing stable version 1 code working.1 There are real migration costs. The Tasks extension moved to an opt-in package that cannot talk to the earlier preview, and McpClient.ServerInfo became nullable in 2.3.36

For companies deploying autonomous agents, the release removes the main operational reason to treat MCP servers differently from other services. That makes the remaining gaps stand out: authorization, protection of the continuation token, and governance of which tools an agent can call. Those are now the work that decides whether agent deployments are safe to scale.