Microsoft announced version 2.0 of the official MCP software development kit for C#, alongside implementation of the 2026-07-28 specification. The release changes how MCP servers operate over HTTP by making them stateless by default, adds standardized HTTP headers, and supports multi-round-trip requests that allow tools to request input from the user or language model without relying on a persistent session.
The release targets developers building MCP servers and clients on .NET, while maintaining the operation of stable APIs in version 1.x and supporting the net8.0, net9.0, and net10.0 frameworks, in addition to netstandard2.0 for use with .NET Framework.
Stateless Servers by Default
In previous releases, using Streamable HTTP required completing the initialize and initialized handshake and creating a session, followed by sending an Mcp-Session-Id header with every subsequent request. This linked requests to the server instance that issued the identifier, requiring sticky routing or session transfer when running multiple instances.
The 2026-07-28 specification removes the initialize and initialized handshake and the Mcp-Session-Id header, and carries the protocol version and capabilities in every request. As a result, any server instance can process any request, without requiring sticky sessions or protocol-level shared session stores. This makes deploying MCP servers in serverless, multi-instance, or edge environments closer to running a regular ASP.NET Core application behind a load balancer.
The HttpServerTransportOptions.Stateless option is set to true by default in version 2.0, with the option to enable stateful mode when unsolicited server-to-client messages or session-associated transport state are needed. Sessions remain available as an option, but are no longer the primary setting.
HTTP Headers for Routing and Monitoring
The stateless mode turns an MCP request into a self-contained HTTP POST request, allowing standard infrastructure to handle it like any other HTTP traffic. The specification enables headers such as Mcp-Method and Mcp-Name, along with the ability to promote some tool arguments to Mcp-Param-* headers.
A load balancer, proxy, gateway, or web application firewall can use these headers for routing and monitoring without parsing the JSON-RPC request body. The request body remains the authoritative source; if a header value differs from the value in the body, the server rejects the request with a HeaderMismatch error. The design also supports encoding values not supported in headers, such as non-ASCII values, using a Base64 indicator.
Multi-Round-Trip Requests for Interactive Tools
The Multi Round-Trip Requests feature, or MRTR, adds a way to handle tools that cannot complete their work in a single call. Instead of the server contacting the client through a live session while processing the request, it returns an InputRequiredResult containing input requests and an opaque state named requestState.
The client performs the requested action, such as asking the user for confirmation, invoking a language model, or displaying workspace roots, then resends the same tool call with inputResponses and requestState attached. The process can be repeated for multiple rounds, while continuity information is carried in the payload, so the operation does not require a session.
The high-level McpClient handles MRTR automatically after the appropriate handlers are registered. The release can also use a compatibility bridge with older clients when a stateful session exists. An older client operating without a session cannot perform multi-round-trip interaction, so the tool must provide an alternative path, such as passing the required value directly in a call argument.
Compatibility and Available Packages
Stable, non-obsolete 1.x APIs continue to compile and run under 2.0, while obsolete changes appear as warnings rather than removals. A 2.0 client can use the legacy initialization handshake when connecting to an older server, and a 2.0 server also accepts that handshake from an older client.
The only exception to protocol compatibility is the Tasks extension; its redesigned 2.0 design replaces the experimental Tasks included in the 2025-11-25 specification and is not compatible with it at the interface or protocol level. Tasks is now available in the separate ModelContextProtocol.Extensions.Tasks package, while experimental MCP Apps are included in ModelContextProtocol.Extensions.Apps.
The core packages include ModelContextProtocol.Core for the client and low-level components, ModelContextProtocol for most servers, and ModelContextProtocol.AspNetCore for Streamable HTTP servers. The post indicates that the next focus in the 2.x series will be comprehensive authentication and authorization, based on closer compatibility with OAuth and OpenID Connect.