The Model Context Protocol (MCP) published its 2026-07-28 specification on July 28, 2026, a major revision of the protocol. The headline change is a stateless protocol core: the initialization handshake and the Mcp-Session-Id header are gone, so any request can go to any server instance. The release also adds Multi Round-Trip Requests, header-based routing, cacheable list results, stricter authorization and a formal extensions framework, while deprecating Roots, Sampling and Logging. For anyone running MCP servers in production, it turns a remote server into an ordinary HTTP workload, and it comes with breaking changes to plan for.

Key Facts#

  • Release: July 28, 2026, announced by lead maintainers David Soria Parra and Den Delimarsky, after a release candidate on May 21, 2026 and a ten-week validation window.
  • Stateless core: The initialize/initialized handshake and Mcp-Session-Id header were removed (SEP-2575, SEP-2567). Each request carries its protocol version, client identity and capabilities in _meta.
  • Multi Round-Trip Requests (SEP-2322): Servers that need more input mid-call return an input_required result, and clients retry with the answers. This replaces server-initiated elicitation, sampling and roots requests.
  • Routing and caching: Mcp-Method and Mcp-Name HTTP headers (SEP-2243) let gateways route without parsing bodies, and list results carry ttlMs and cacheScope hints (SEP-2549).
  • Deprecations: Roots, Sampling, Logging and the legacy HTTP+SSE transport are deprecated (SEP-2577), with at least twelve months before any removal under a new feature lifecycle policy.
  • SDKs: All Tier 1 SDKs, TypeScript, Python, Go and C#, were updated. The C# SDK's version 2.0.0 shipped the same day.

What Happened#

Earlier versions of MCP assumed a connection: a client initialized a session, and the server tracked it. That worked for local servers over stdio but made remote deployments awkward, because every request from a client had to reach the instance that held its session, which required sticky routing or shared session stores. The release candidate announcement stated the goal plainly: deployments can now sit behind "plain round-robin load balancers."

To remove sessions without losing capability, the maintainers replaced the features that depended on the server calling back into the client. Under Multi Round-Trip Requests, a server that needs input returns a result with resultType: "input_required" describing what it needs, and the client retries the call with inputResponses. Applications that need state between calls pass explicit handles, identifiers threaded through tool calls, which the maintainers noted also makes that state visible to the model rather than hidden in transport metadata.

Operations teams get several direct wins. The new Mcp-Method and Mcp-Name headers let API gateways route and authorize requests without inspecting JSON bodies. Cache directives modeled on HTTP let clients decide how long tools/list and similar responses stay fresh. Tool schemas now support full JSON Schema 2020-12, and W3C Trace Context propagation uses standardized keys.

Authorization was hardened across six SEPs. Clients must validate the iss parameter per RFC 9207 (SEP-2468), dynamic client registration declares an application_type (SEP-837), credentials are bound to the authorization server that issued them (SEP-2352), and Dynamic Client Registration is formally deprecated in favor of Client ID Metadata Documents.

Finally, extensions became first-class. They carry reverse-DNS identifiers and independent versions. Tasks, experimental in the previous revision, moved into its own extension (SEP-2663), joining MCP Apps as an official extension.

Background#

The previous revision, 2025-11-25, arrived on MCP's first anniversary with experimental tasks, Client ID Metadata Documents for simpler authorization and URL-mode elicitation. Two weeks later the protocol moved to the Linux Foundation's Agentic AI Foundation, by which point Anthropic reported more than 10,000 active public servers. Running servers at that scale exposed the cost of sessions, transport evolution became a priority of the March 2026 roadmap, and removing sessions became the centerpiece of this release.

The maintainers paired the specification with process changes. SDKs are now scored against a conformance suite in a tier system, Tier 1 SDKs had to ship support within the ten-week window, and Standards Track SEPs need matching conformance scenarios before they can be finalized. Beta SDKs appeared on June 29, 2026, including version 2.0.0-preview.1 of the C# SDK.

Why It Matters for Developers#

For .NET teams, the C# SDK's 2.0.0 release makes the new model the default. Its release notes say stateless HTTP is now on by default, clients probe the new server/discover operation and fall back to the initialize handshake for older servers, and down-level interoperability with the 2025-11-25 and earlier revisions remains. The SDK's current source describes three session modes, including a hybrid mode added in version 2.2 for servers that must still serve older clients:

C#
using System.ComponentModel;
using ModelContextProtocol.AspNetCore;
using ModelContextProtocol.Server;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddMcpServer()
    // Stateless is the default. This mode also keeps sessions for older clients
    // that still use the initialize handshake.
    .WithHttpTransport(o => o.SessionMode = HttpServerSessionMode.StatefulForInitializeClients)
    .WithTools<InventoryTools>();

var app = builder.Build();
app.MapMcp();
app.Run();

[McpServerToolType]
public sealed class InventoryTools
{
    private static readonly Dictionary<string, int> Stock = new() { ["SKU-1"] = 42 };

    [McpServerTool, Description("Returns the number of units in stock for a SKU.")]
    public static int GetStock(string sku) => Stock.GetValueOrDefault(sku);
}

Key migration points, drawn from the specification and the SDK notes:

  • Scale out freely. Stateless servers work behind standard load balancers, which simplifies hosting on Kubernetes or any container platform.
  • Move Tasks code. Tasks now live in the ModelContextProtocol.Extensions.Tasks package, so code using the experimental core Tasks API must switch to the extension.
  • Replace deprecated features. The maintainers suggest tool parameters or configuration instead of Roots, direct model provider APIs instead of Sampling, and standard error output or OpenTelemetry instead of Logging. The C# SDK now raises warnings for these APIs. Our OpenTelemetry in .NET guide covers the logging side.
  • Recheck authorization. The SDK validates issuer mismatches and requires explicit PKCE S256 support in authorization server metadata, so older identity setups may need updates.
  • Watch error codes. A missing resource now returns the standard JSON-RPC -32602 instead of -32002, which breaks clients that match the old literal.

Our MCP in C# guide and the story on the C# SDK 1.0 release provide background on the SDK's earlier design.

What's Next#

The C# SDK moved quickly after the release, adding hybrid stateful and stateless serving in version 2.2.0 in August 2026. On August 22, 2026, the maintainers published a new roadmap with five priorities: agentic messaging primitives such as server-initiated events and a maturing Tasks extension; unifying transports around HTTP, including for local servers; agent identity and enterprise security through DPoP, workload identity federation and token exchange; improved primitives such as progressive tool discovery; and better SDK developer experience. No date has been announced for the next specification release.

The deprecated features remain functional for at least twelve months, so the open question for most teams is timing rather than feasibility: when to adopt the stateless model, and how long to keep serving clients that still depend on sessions.

Sources#