On April 2, 2025, Microsoft announced that it had partnered with Anthropic to build an official C# SDK for the Model Context Protocol (MCP), the open standard Anthropic created to connect AI applications with tools and data. The SDK ships on NuGet as ModelContextProtocol and lives in the protocol's own GitHub organization, so .NET developers now have a supported way to build MCP servers and clients instead of choosing among community libraries. For teams planning AI agents in C#, the announcement put .NET on both sides of the protocol while MCP adoption was still accelerating.

Key Facts#

  • Announcement: Microsoft published the news on its developer blog on April 2, 2025. The same day, Anthropic's David Soria Parra posted on X that there was now an official C# MCP SDK.
  • Package: ModelContextProtocol on NuGet, released as a 0.1.0 preview.
  • Repository: modelcontextprotocol/csharp-sdk on GitHub, which describes itself as the official C# SDK for MCP servers and clients, maintained in collaboration with Microsoft.
  • Origins: the code base started from mcpdotnet, a community project created by Peder Holdgaard Pedersen, whom Microsoft credited in its announcement.
  • Early traction: press coverage at the time noted that the package had already passed 21,000 downloads while still at version 0.1.0-preview.8.
  • Stable release: version 1.0.0 was published to NuGet on February 25, 2026.

What Happened#

Microsoft framed the SDK as a response to how quickly MCP was being adopted across the AI tooling world. Rather than write a new library from scratch, the .NET team adopted mcpdotnet, which had already proven the design in the community, and moved the code into the modelcontextprotocol organization next to the protocol's other official language SDKs. That decision matters for governance: the C# SDK follows the specification in the same place as the specification itself, with Microsoft engineers contributing alongside the protocol maintainers.

The programming model will feel familiar to anyone who has written an ASP.NET Core or worker service. A server is an ordinary .NET host. You register it with AddMcpServer(), choose a transport, and let the SDK discover tools through attributes. A class marked [McpServerToolType] groups tools, each method marked [McpServerTool] becomes a callable tool, and Description attributes on methods and parameters become the metadata that a language model reads when it decides which tool to call. Dependency injection works as it does elsewhere in .NET, so tools can take services such as an HttpClient or a repository as parameters.

The client side of the SDK connects to any MCP server, lists its tools, resources and prompts, and invokes them. Its tool objects derive from AIFunction in Microsoft.Extensions.AI, so a list of MCP tools can be passed straight into the options of an IChatClient call and invoked automatically by the function-invocation middleware. That integration is the main reason the SDK fits so naturally into the rest of Microsoft's AI stack for .NET.

Background#

Anthropic introduced MCP on November 25, 2024, describing it as a new standard for connecting AI assistants to the systems where data lives, and published the specification together with SDKs on GitHub. It is an open, client-server protocol: servers expose tools (actions), resources (data) and prompts (reusable templates), and clients such as chat apps, IDEs and agents discover and use them through a common JSON-RPC interface. The pitch was simple: build an integration once and use it from any MCP-compatible host, rather than writing a custom plug-in for every assistant.

By the spring of 2025, adoption was accelerating, which is the context Microsoft cited for the partnership, and Microsoft was adding MCP support to its own tools. Visual Studio Code 1.99, released in early April 2025, added support for MCP servers in agent mode. On the library side, Microsoft had shipped the first preview of Microsoft.Extensions.AI in October 2024, which introduced the IChatClient and AIFunction abstractions that the MCP SDK builds on. An official C# SDK was the missing piece that let .NET developers publish their own MCP servers with the same confidence as those building in TypeScript or Python.

Why It Matters for Developers#

The most immediate benefit is that existing .NET business logic can become agent-accessible with very little code. An order-lookup service, an inventory query or an internal knowledge search can be wrapped as MCP tools and used from VS Code, other MCP hosts or your own agents. The minimal server from the SDK's getting-started guide shows the whole shape of it:

C#
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using ModelContextProtocol.Server;
using System.ComponentModel;

var builder = Host.CreateApplicationBuilder(args);

// stdout carries the protocol, so send every log line to stderr.
builder.Logging.AddConsole(o => o.LogToStandardErrorThreshold = LogLevel.Trace);

builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()
    .WithToolsFromAssembly();

await builder.Build().RunAsync();

[McpServerToolType]
public static class EchoTool
{
    [McpServerTool, Description("Echoes the message back to the client.")]
    public static string Echo(string message) => $"hello {message}";
}

A few practical lessons follow from this design:

  • Mind the transport. With the stdio transport, standard output carries JSON-RPC messages. Any stray Console.WriteLine or default console logging corrupts the stream, which is why the sample routes logs to standard error.
  • Write descriptions for the model, not for humans. Tool and parameter descriptions are effectively prompt text. Vague descriptions lead to wrong tool choices, so treat them as part of your API contract. Our guide to function calling in C# covers the same principle for plain tool use.
  • Treat servers as privileged code. An MCP tool runs with whatever permissions its host process has. Apply least privilege, validate arguments as you would for a public API, and require confirmation for destructive actions. The responsible AI and LLM security guide goes deeper on prompt injection through tool results.
  • Expect churn in previews. The April 2025 release was a 0.1 preview, and several APIs changed before 1.0. Pin package versions and read release notes before upgrading.

On the consuming side, the AIFunction integration means you do not need a separate tool abstraction for MCP. Tools from a remote server and tools written in your own code flow through the same Microsoft.Extensions.AI pipeline, which keeps agent code provider-neutral.

What's Next#

The April 2025 package was an early preview, and because the MCP specification itself was still moving quickly, the preview label was a real warning rather than a formality. The project matured steadily from there. A low-dependency ModelContextProtocol.Core package appeared in June 2025 for clients and low-level servers, and today the SDK ships as three packages: ModelContextProtocol.Core, the main ModelContextProtocol package with hosting and dependency injection extensions, and ModelContextProtocol.AspNetCore for HTTP-based servers. The SDK reached a stable 1.0.0 release in February 2026, covered in our story on the MCP C# SDK 1.0 release, and a 2.0.0 release followed on NuGet in July 2026.

If you are starting today, begin with the current stable packages and our MCP in C# guide rather than code samples from the preview era, and review AI agents and MCP interview questions if you need to explain the architecture to your team.

Sources#