If your team lives in .NET, you no longer have to bridge to Node or Python to ship an MCP server. The official ModelContextProtocol C# SDK — one of the four Tier 1 SDKs, now past 1.4 on NuGet — pairs with a first-party dotnet new mcpserver template, and NuGet itself hosts and distributes the finished server. Here's the minimal version that a real user can install.
The three packages
The SDK is split so you only pull what you need. ModelContextProtocol.Core is the low-level client and server APIs with minimum dependencies. ModelContextProtocol is the main package, adding hosting and dependency-injection extensions — the right default for most servers. ModelContextProtocol.AspNetCore is the one to add when you want an HTTP-based server rather than stdio. For a first local server, the middle package is all you touch.
Scaffold with the template
.NET 10 ships an MCP template, so you skip the boilerplate entirely:
dotnet new install ModelContextProtocol.Templates
dotnet new mcpserver -n WeatherMcp
cd WeatherMcp
dotnet build
That generates a self-contained tool package that targets the common platforms by default. Run dotnet new mcpserver --help to see the options — HTTP transport, sample tools, and packaging flags among them.
The tool
Tools are plain methods decorated with attributes; the SDK reflects over them to build the schema and wire up dependency injection. A minimal server exposing one tool looks like this:
using System.ComponentModel;
using ModelContextProtocol.Server;
[McpServerToolType]
public static class WeatherTool
{
[McpServerTool, Description("Current weather for a city")]
public static string GetWeather(
[Description("The city to look up")] string city)
=> $"{city}: 18°C, partly cloudy";
}
The host wiring — AddMcpServer().WithStdioServerTransport().WithToolsFromAssembly() in Program.cs — is filled in by the template, so you edit tools, not plumbing.
Test it
dotnet run
npx @modelcontextprotocol/inspector dotnet run
The inspector lists your tools and lets you call GetWeather with a sample argument before any host sees it. To run it inside Claude Desktop, point the config at the built binary or dotnet run with the project path, restart, and the tool shows under the hammer icon.
Publish to NuGet
This is where C# has an edge: NuGet now supports hosting and consuming MCP servers built with the SDK, so distribution is dotnet pack then dotnet nuget push. Users install your server the same way they install any .NET tool, and it shows up in NuGet's MCP listings. Set the MCP metadata in the .csproj first so hosts can discover the transport and entry point.
Where to go next
Coming from another stack? The Python tutorial and Node.js walkthrough cover the same concepts, and Go gets its own guide. Pick a transport with Streamable HTTP vs SSE vs stdio, then read the 2026-07-28 spec changes before you expose an HTTP endpoint. When it's ready, publish it to the registry and submit it to the directory — curated, categorised and vetted, usually live within 24 hours.