The official Model Context Protocol (MCP) C# SDK reached version 1.0.0 on February 25, 2026, ending an almost eleven-month preview that began when Microsoft and Anthropic launched the project in April 2025. The stable release commits the ModelContextProtocol packages to Semantic Versioning, clearly separates experimental APIs from supported ones, and targets the 2025-11-25 revision of the MCP specification. For .NET teams that held off on shipping MCP servers and clients in production because of constant API churn, this is the release that makes a long-term commitment reasonable.

Key Facts#

  • Release: ModelContextProtocol 1.0.0 was published to NuGet on February 25, 2026, one day after 1.0.0-rc.1.
  • Packages: ModelContextProtocol.Core (client and low-level server APIs with minimal dependencies), ModelContextProtocol (hosting and dependency injection extensions) and ModelContextProtocol.AspNetCore (HTTP-based servers).
  • Targets: .NET 8 and later, plus .NET Standard 2.0.
  • Stability promise: the project follows Semantic Versioning, so breaking changes to stable APIs require a new major version.
  • Experimental APIs: features that are still settling carry the [Experimental] attribute with MCPEXP diagnostic IDs, so using them is an explicit opt-in.
  • Specification: the 1.x line implements the MCP 2025-11-25 revision, including URL-based client registration through Client ID Metadata Documents and URL-mode elicitation.
  • Follow-ups: versions 1.1.0 and 1.2.0 shipped in March 2026, and 2.0.0 arrived on July 28, 2026.

What Happened#

The final stretch to 1.0 was compressed into a single week. Version 0.9.0-preview.1, released on February 20, 2026, bundled eight breaking changes and told users that the stable release would land early in the week of February 23. Those changes were the kind that are painful after 1.0 and cheap before it. Binary content moved from strings to ReadOnlyMemory<byte> to avoid needless UTF-16 transcoding, filter registration was split into separate WithMessageFilters and WithRequestFilters callbacks, server handlers moved into McpServerOptions, and the HTTP transport began rejecting invalid protocol-version headers, as well as stateful requests other than initialization that arrive without a session ID.

The release candidate followed on February 24. Its notes describe a full audit of the public API surface ahead of the stable release, which produced another round of cleanups. McpClientHandlers was sealed to match McpServerHandlers, Tool.Name became required, obsolete filter extension methods were removed, and the default number of reconnection attempts for clients rose from two to five. Subclassing McpClient and McpServer was put behind an experimental diagnostic rather than being promised as a stable extension point.

Version 1.0.0 then shipped on February 25 with one last adjustment: HttpServerTransportOptions.RunSessionHandler was marked experimental under diagnostic MCPEXP002. The release notes steer developers toward ConfigureSessionOptions instead and warn that the handler may change or be removed later. The maintainers described the release as the SDK's first stable version and credited community contributors for getting it there.

Background#

When the C# SDK debuted in April 2025 (see our coverage of the official MCP C# SDK launch), it was a 0.1 preview built on the community mcpdotnet project. The preview period that followed was busy because the specification itself kept moving. The SDK split out a low-dependency Core package in June 2025. In December 2025, version 0.5.0-preview.1 removed the older McpClientFactory and McpServerFactory APIs, consolidated per-call parameters into a RequestOptions bag, and added features from the November 2025 specification, such as Client ID Metadata Documents for URL-based OAuth client registration and URL-mode elicitation.

The stable release also fits a broader pattern in Microsoft's .NET AI stack in early 2026. The Microsoft.Extensions.AI.OpenAI adapter shipped its first stable version, 10.3.0, on February 10, 2026, and Microsoft Agent Framework was closing in on its own 1.0. MCP tools are a core ingredient in both, so a stable protocol library removes one of the last preview dependencies from production agent architectures.

Why It Matters for Developers#

Stability changes the risk calculation. Before 1.0, every minor preview could rename types or reshape handler registration, which made MCP servers expensive to maintain inside enterprise codebases with slow upgrade cycles. With the SemVer commitment, a server written against 1.0 should keep compiling across 1.x releases, and anything that might still change is flagged at compile time through MCPEXP diagnostics. If your build treats warnings as errors, those diagnostics become a useful guardrail: you have to suppress them deliberately, which documents exactly where you depend on unstable surface area.

The client API is also a good fit for existing Microsoft.Extensions.AI code. MCP tools returned by ListToolsAsync derive from AIFunction, so they can be handed to any IChatClient:

C#
using Microsoft.Extensions.AI;
using ModelContextProtocol.Client;

await using var mcp = await McpClient.CreateAsync(new StdioClientTransport(new()
{
    Name = "Everything",
    Command = "npx",
    Arguments = ["-y", "@modelcontextprotocol/server-everything"],
}));

IList<McpClientTool> tools = await mcp.ListToolsAsync();

// chatClient should be built with UseFunctionInvocation() so tool calls run automatically.
ChatResponse response = await chatClient.GetResponseAsync(
    "Use the echo tool to say hello.",
    new ChatOptions { Tools = [.. tools] });

Practical steps for teams upgrading from the previews:

  • Budget real migration time. Projects still on 0.4 or earlier will hit the factory removals, the RequestOptions change, the new filter APIs and the binary-content change all at once. Upgrade in stages and let the compiler guide you.
  • Audit experimental usage. Search for suppressed MCPEXP001, MCPEXP002 and MCPEXP003 warnings, and keep that code isolated behind your own interfaces.
  • Revisit HTTP hosting. The stricter session and protocol-version validation can surface misbehaving clients or proxies that previously worked by accident.
  • Treat OAuth as part of the upgrade. URL-based client registration simplifies connecting clients to protected remote servers, but it deserves the same review as any other identity integration. Our ASP.NET Core authentication guide covers the underlying OAuth and OpenID Connect concepts.

For a full walkthrough of servers, clients and transports, see our MCP in C# guide, and for how MCP tools slot into agent designs, see Microsoft Agent Framework.

What's Next#

The versioning policy spells out what happens after 1.0: only the latest major version receives new features and bug fixes, while critical bugs may be patched in the previous major version's latest minor release. That policy took effect quickly. Minor releases 1.1.0 and 1.2.0 followed in March 2026, and version 2.0.0 shipped on July 28, 2026, targeting the 2026-07-28 revision of the specification while negotiating backward compatibility with 2025-11-25 servers and clients during the protocol handshake.

For teams that just finished moving to 1.x, the practical question is how long to stay there. Since the 1.x line now receives only critical fixes, plan the move to 2.x as part of normal maintenance rather than as an emergency, and track deprecation warnings, which use MCP9xxx diagnostic IDs, as early signals of what the next major version will remove.

Sources#