ModelContextProtocol/csharp-sdk: A Package Split That Decides Your Dependency Graph
The official C# SDK for Model Context Protocol servers and clients. Maintained in collaboration with Microsoft.
At a glance
- What is it?
- The official C# SDK for the Model Context Protocol ships as five NuGet packages rather than one, and the README treats picking the right one as the first real decision. Here is what each package pulls in, what the README does not tell you, and where the SDK stops being the right tool.
- Who is it for?
- Adopt ModelContextProtocol.Core if you are writing a client or a low-level server and want the smallest dependency surface, and ModelContextProtocol.AspNetCore only if you are actually hosting MCP over HTTP. Do not adopt it expecting the README to teach you the protocol: it points at the getting-started guide and the samples directory instead.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is not MCP itself, it is which of the five packages you install
The Model Context Protocol standardizes how applications hand context to large language models, and this repository is the official C# implementation of both sides of that conversation. .NET applications, services and libraries can act as MCP clients, as MCP servers, or as both. That is the stated scope, and it is broad enough that a single package would have forced every consumer to carry dependencies it never calls. The README answers that by splitting the SDK five ways. ModelContextProtocol.Core is for projects that only need the client or the 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. Two extension packages sit on top: ModelContextProtocol.Extensions.Apps for interactive UI applications that render inside MCP hosts, and ModelContextProtocol.Extensions.Tasks for long-running tool invocations with status polling and input requests. The audience is therefore not one group. It is a console tool that speaks to someone else's MCP server, a web service that exposes tools over HTTP, and a desktop host that renders MCP Apps, and the README expects each to pick a different starting point. If you cannot say which of those three you are building, the package decision is the thing to resolve before writing any code.
What the layering actually buys you, and what it costs
The reference chain is explicit in the README: AspNetCore references ModelContextProtocol, which references Core. That means installing the AspNetCore package transitively brings in the hosting and dependency injection extensions whether or not you use them, and installing ModelContextProtocol brings in Core. The only package that lets you avoid the hosting layer is Core itself. This is a deliberate trade: the deeper you go, the fewer things arrive in your dependency graph, and the more wiring you do yourself. The README does not quantify that difference. It does not say how many transitive dependencies each package carries, and it gives no size figures. Anyone who needs those numbers should read the .nuspec or the project files rather than the README, because the README only tells you the direction of the reference, not the weight. The same applies to the two extension packages. Extensions.Tasks is described as running long-running tool invocations asynchronously with status polling and input requests, which implies a polling loop somewhere in your code or in the library, but the README does not say which. Extensions.Apps is described as building interactive UI applications that render inside MCP hosts, which makes it useful only if your target host renders MCP Apps at all. Neither extension is a default. They are opt-in layers for specific host behaviours, and the README treats them that way.
Identity Assertion Authorization Grant: the one feature the README names by type
Most of the README defers to external documentation, but it does single out one capability with a concrete API name. The SDK provides support for the Identity Assertion Authorization Grant flow via IdentityAssertionGrantProvider, and the README points to the Cross-Application Access section of the transport documentation for full usage details. That section lives at docs/concepts/transports/transports.md in the repository. This is the enterprise-managed authorization path: an application asserts an identity to obtain a grant rather than walking a user through an interactive consent screen each time. The README links the draft specification in the modelcontextprotocol/ext-auth repository, which is worth noting because the target is a draft, not a frozen specification. A type named IdentityAssertionGrantProvider is the kind of detail that matters when you are wiring authentication, because it tells you the SDK has an opinion about where that logic lives rather than leaving it entirely to your middleware. What the README does not give you is a code sample, a configuration shape, or a statement about which transports support the flow. For that you have to open the transport document. Treat the README line as a signpost, not as an implementation guide.
Getting it running means leaving the README
The README does not contain an install command, a server registration snippet, or a client connection example. It says to see the Getting Started guide in the conceptual documentation for installation instructions, package-selection guidance, and complete examples for both clients and servers, and it points at the samples directory and the API documentation at csharp.sdk.modelcontextprotocol.io. So the honest sequence is: choose a package from the list, then go to the Getting Started page, then read the sample that matches your role. The package names themselves are the only concrete identifiers the README hands you: ModelContextProtocol.Core, ModelContextProtocol, ModelContextProtocol.AspNetCore, ModelContextProtocol.Extensions.Apps, ModelContextProtocol.Extensions.Tasks. Every one of them is published on NuGet, and the README embeds version badges for each. That is a real constraint on how you evaluate this project. You cannot judge the API surface from the repository front page, and you cannot copy a working configuration out of it. If your evaluation process depends on a quickstart that fits in one screen, this README will not satisfy it, and the documentation site is where the actual onboarding cost sits. Budget for that reading before you decide the SDK is or is not a fit.
Licence: the README and the repository metadata disagree
The README states that the project is licensed under the Apache License 2.0 and links a LICENSE file. The repository metadata supplied for this review reports the licence as NOASSERTION, which is what GitHub records when it cannot map the licence file to a recognised identifier. Those two statements are not necessarily in conflict: a LICENSE file that GitHub's detector cannot classify will still be an Apache 2.0 text if that is what it contains. But the discrepancy is worth resolving before you depend on the terms, because the answer lives in the file, not in either summary. Apache 2.0 carries an explicit patent grant and requires that you preserve notices and state changes, which matters if you vendor or modify the SDK. The README also does not say whether the extension packages carry the same licence as the core ones. Read the LICENSE file and the package metadata for each package you install. This is not legal advice, and if the terms affect a commercial distribution, that is a question for your own counsel.
Where this SDK is the wrong choice
Two limitations are visible from the material alone. First, the SDK is C# and .NET. If your server is a Python service, a Node process, or a Go binary, nothing here helps you, and the MCP organisation publishes SDKs for other ecosystems. Second, the package split means a project that needs HTTP server capability cannot stay on the minimal package. If you install ModelContextProtocol.Core because you want the smallest dependency set and later discover you need to host MCP over HTTP, you move to ModelContextProtocol.AspNetCore and inherit the hosting and dependency injection layers along with it. The README frames the choice as one you make up front, and that framing is a genuine constraint rather than a stylistic preference. A third case is thinner but real: the two extension packages target specific host behaviours. If your host does not render MCP Apps, Extensions.Apps has nothing to do. If your tool calls return quickly, the polling and input-request machinery in Extensions.Tasks is overhead. The README does not describe fallback behaviour when a host lacks support for an extension, so that is a question to answer from the extension documentation before you build on it.
The alternative is writing against the protocol yourself
The realistic alternative is not a competing C# library. It is implementing the MCP wire format directly against the specification, which the README links at modelcontextprotocol.io/specification. The difference in approach is stark. Writing it yourself means you own the JSON-RPC framing, the capability negotiation, the transport handshakes, and every protocol revision that lands after you ship. This SDK means you inherit that work and, in exchange, accept its release cadence and its abstractions. The release history shows why that trade has teeth: v2.0.0, v2.1.0 and v2.2.0 all landed within roughly a month of each other in mid-2026, and the repository shows a push in September 2026. A major version bump inside that window is the kind of event that forces a migration in dependent code. If you have implemented the protocol yourself, those bumps do not reach you. If you have not, you are tracking them. There is no third option where you get the protocol maintenance for free and also control the API surface. The choice is between owning the protocol and owning the upgrade.
Maintenance cost and what to verify before you commit
The upgrade cost is set by that release cadence. Three releases in about four weeks, one of them a major version, means the SDK is moving quickly and that pinning a version is the default posture rather than floating one. The README offers no migration guide, no changelog summary, and no statement about API stability between major versions. The repository is not archived and the last push is recent, so the project is active, but activity is not the same as stability, and the material here does not let you conclude either way about compatibility guarantees. The practical checks are concrete. Read the Getting Started page and confirm which package its example installs, because that tells you what the maintainers consider the default path. Open docs/concepts/transports/transports.md and read the Cross-Application Access section if you need the Identity Assertion Authorization Grant flow, since the README gives you the type name and nothing else. Read the LICENSE file to settle the Apache 2.0 question. And look at the samples directory for whichever role you are building, client or server, because that is where working code lives. If those four places answer your questions, the SDK is worth adopting. If the Getting Started guide assumes a package you had already ruled out, you have learned something about the intended default before writing a line of code.
Editorial conclusion
Adopt ModelContextProtocol.Core if you are writing a client or a low-level server and want the smallest dependency surface, and ModelContextProtocol.AspNetCore only if you are actually hosting MCP over HTTP. Do not adopt it expecting the README to teach you the protocol: it points at the getting-started guide and the samples directory instead. Before you commit, open the Getting Started page, confirm which package its example installs, and check the licence file in the repository, because the GitHub licence field reports NOASSERTION while the README states Apache License 2.0.
Community notes