MCP C# SDK: building MCP clients and servers in .NET

What the MCP C# SDK is for, and who should pick it

MCP standardises how an application hands context and tools to a large language model. The C# SDK is the official .NET implementation of that protocol on both sides: it lets a .NET service act as an MCP server that exposes tools, and it lets a .NET application act as an MCP client that calls them. The README describes it as enabling .NET applications, services, and libraries to implement and interact with MCP clients and servers.

The audience is narrower than the phrase .NET developer suggests. If you already run a C# service that holds business logic an LLM should be able to call, this is the shortest route to exposing it. If you are writing a desktop or console tool that needs to consume someone else's MCP server, the same SDK covers that direction. What it is not is a model client: it speaks MCP to servers, not to an inference API. A team expecting the SDK to talk to a model provider will find it sits one layer below that.

The repository is maintained in collaboration with Microsoft, which matters for anyone deciding between this and an independent C# MCP implementation. The last push to main was on 2026-09-09, so the codebase is moving.

Four packages, and why the split decides your dependency graph

The SDK ships as four NuGet packages, and the README is explicit that the choice is about dependencies rather than features. ModelContextProtocol.Core is for projects that only need the client or low-level server APIs and want the minimum number of dependencies. ModelContextProtocol adds hosting and dependency injection extensions and references Core; the README calls it the right fit for most projects that do not need HTTP server capabilities. ModelContextProtocol.AspNetCore is for HTTP-based MCP servers and references ModelContextProtocol. ModelContextProtocol.Extensions.Apps covers MCP Apps, for interactive UI that renders inside MCP hosts.

That layering is the main design decision a reader has to internalise. A console client that references ModelContextProtocol.AspNetCore inherits an ASP.NET Core dependency it will never exercise. The reverse mistake is cheaper but still annoying: starting on Core and then discovering you want the hosting extensions means adding a reference and rewriting your startup path.

The protocol work itself lives in Core, so a low-level server implementation is possible without the DI layer. The README does not spell out what the low-level server API looks like; it points at the API documentation for available functionality, and the samples directory for worked examples. Treat the samples as the real specification of the intended shape of a server.

There is also a fifth package, ModelContextProtocol.Extensions.Tasks, described as the MCP Tasks extension for running long-running tool invocations asynchronously with status polling and input requests. It is not part of the core four, and the README lists it under the same Packages heading.

Installing the MCP C# SDK and running a first server

The README does not inline installation commands. It points to the Getting Started guide in the conceptual documentation for installation instructions, package-selection guidance, and complete examples for both clients and servers. So the commands below are the standard NuGet ones for the package names the README lists, not a transcript of a documented walkthrough.

Pick the package first. For a console or worker service that exposes tools without HTTP, the middle package is the documented default for most projects:

dotnet add package ModelContextProtocol

If you are building an HTTP-based MCP server, the README says to use the ASP.NET Core package, which pulls in the two below it:

dotnet add package ModelContextProtocol.AspNetCore

And if you want the client or low-level server APIs with the minimum number of dependencies, reference Core directly:

dotnet add package ModelContextProtocol.Core

After restoring, the next step is not guesswork: the repository ships samples/QuickstartClient, samples/QuickstartWeatherServer, samples/AspNetCoreMcpServer and samples/InMemoryTransport among others. Open the sample that matches your host rather than starting from an empty project, because the README does not document the server registration API in prose.

For building the repository itself, the Makefile defines the targets. A full build is restore plus build, and the default goal is build:

make build

Running the test suite goes through the same Makefile and filters out tests marked Manual, with hang detection set to seven minutes:

make test

The Makefile also defines test-aot, which publishes tests/ModelContextProtocol.AotCompatibility.TestApp and runs it, and pack, which runs dotnet pack. If you care about native AOT compatibility, that target exists to check it.

Cross-application access and the identity assertion grant flow

The README documents one enterprise-facing feature in detail: support for the Identity Assertion Authorization Grant flow via IdentityAssertionGrantProvider. The full usage details are not in the README; it points to the Cross-Application Access section of the transport documentation under docs/concepts/transports/transports.md.

This is the part of the SDK aimed at managed deployments rather than local tool servers. A developer running an MCP server on their own machine will not touch it. A team wiring an MCP server into an existing enterprise identity system will, and the fact that the implementation is named as a provider class rather than described as a general OAuth story is a useful signal: the SDK supports this specific flow, and the README does not claim to cover every authorization pattern.

The transport documentation is where the real detail lives. Anyone evaluating this for a protected deployment should read that file before deciding, because the README gives the provider name and a link, and nothing about configuration keys, token lifetimes or failure behaviour.

Where the MCP C# SDK is the wrong tool

The clearest limitation is stated by omission. The README lists packages for client, server, HTTP server, apps and tasks, and describes transports only through links. There is no stdio-versus-HTTP decision table in the README, no documented list of supported transport types, and no rollback or versioning guidance. If your architecture depends on a transport the SDK does not implement, you will find that out from the transport documentation, not from the front page.

The second constraint is the dependency layering itself. Because ModelContextProtocol references Core and AspNetCore references ModelContextProtocol, you cannot take the HTTP server package without taking the DI and hosting extensions. That is fine for an ASP.NET Core application and wasteful for a minimal one.

The third is scope. This is an MCP implementation, not an agent framework. It does not decide when a model should call a tool, does not manage prompts, and does not talk to a model provider. If what you actually need is a library that orchestrates model calls, this SDK is a component inside that library, not a replacement for it. The related searches that pair this project with model-vendor SDK names point at that confusion; those are different layers of the stack.

Finally, the licence file is present but the repository metadata reports the licence as NOASSERTION, while the README states the project is licensed under the Apache License 2.0 with a link to LICENSE. Read LICENSE itself rather than either signal.

Alternatives, and the real difference in approach

The honest alternative to this SDK is implementing MCP against the protocol specification directly, using the specification at modelcontextprotocol.io/specification and your own JSON-RPC layer. The difference is not effort in the abstract; it is that you own the wire format, the session lifecycle and the capability negotiation yourself, in exchange for zero dependency on this project's release cadence. Teams that already have a JSON-RPC stack and only need one narrow capability sometimes prefer that.

The second alternative is a third-party C# MCP library. The distinguishing fact here is provenance: this SDK is the official implementation, maintained in collaboration with Microsoft, and the repository carries a conformance test setup, with @modelcontextprotocol/conformance pinned in package.json alongside server-everything and server-memory. A third-party library may track the specification faster in a specific area, but it will not be the reference the specification authors test against.

Note what is not an alternative: a different language SDK. If your service is C#, dropping to Python or TypeScript for the MCP layer means a second process and an IPC boundary. That is a legitimate design, but it is a different architecture, not a swap.

Maintenance cost, licence and what to verify before committing

The release cadence is visible: v2.0.0 on 2026-07-28, v2.1.0 on 2026-08-05, v2.2.0 on 2026-08-13, with the last push to main on 2026-09-09. Three minor-or-major releases inside three weeks is a fast-moving surface. Pin your package versions and read the release notes before upgrading, because a minor bump in a protocol SDK can change wire behaviour.

Upgrade cost is concentrated in the package boundary you chose. A Core-only client has the smallest surface to re-test. An ASP.NET Core server has the largest, because it inherits the hosting and DI extensions as well.

The repository is a .NET solution, ModelContextProtocol.slnx, with Directory.Build.props, Directory.Packages.props and global.json at the root. If you build from source, the pinned SDK version in global.json and the central package versions in Directory.Packages.props are the two files that determine what you get. There is also a package-lock.json and package.json pinning npm dependencies for conformance tests, which is separate from the NuGet graph.

On licence: the README states Apache License 2.0 and links LICENSE, while the repository metadata reports NOASSERTION. Apache 2.0 includes an explicit patent grant, which matters for a protocol implementation you might ship in a product, but confirm the actual LICENSE file and your own obligations rather than relying on either summary. This is not legal advice.

Before committing, verify three things: that the transport you need is covered in docs/concepts/transports/transports.md, that the sample closest to your host (QuickstartWeatherServer, AspNetCoreMcpServer, InMemoryTransport, ProtectedMcpServer) actually compiles against the package version you pinned, and that the AOT target matters to you, in which case run make test-aot.

Editorial conclusion

Adopt it if you are building an MCP server or client in .NET and want the reference implementation rather than a third-party wrapper; the package split lets a console app stay on ModelContextProtocol.Core. Do not adopt it if you are not on .NET, or if you need a transport the SDK does not ship. Before writing code, read the Getting Started guide for package-selection guidance and check which of ModelContextProtocol, ModelContextProtocol.AspNetCore or ModelContextProtocol.Core matches your host, because the wrong choice pulls in dependencies you will not use.

Frequently asked questions

Official sources

1. Issues
2. modelcontextprotocol/csharp-sdk on GitHub
3. Project website
4. README
5. Releases