How to Build MCP Servers with .NET: A C# Developer's Guide

Why Build MCP Servers in .NET?

For years, enterprise development has relied on the stability and performance of the .NET ecosystem. Now, as AI agents become central to workflow automation, bridging these legacy systems with modern Large Language Models (LLMs) is a critical challenge. The Model Context Protocol (MCP) provides the standard for this connection.

Building MCP servers in C# offers distinct advantages:

• Type Safety: Leverage C#'s strong typing to define tool schemas and validation logic automatically.
• Ecosystem Access: Connect directly to SQL Server, Entity Framework, and internal NuGet packages without rewriting logic in Python.
• Performance: utilize the high-throughput capabilities of ASP.NET Core for SSE (Server-Sent Events) transports.

Instead of building a separate "AI layer" in Python, you can expose your existing domain services directly to agents like Claude and IDEs like Cursor.

Prerequisites and Project Setup

To get started, you will need the .NET 8 SDK or newer. Microsoft has streamlined the process with dedicated project templates that handle the boilerplate configuration for both local (stdio) and remote (SSE) servers.

Installing the Templates

Open your terminal and install the official MCP templates:

dotnet new install Microsoft.McpServer.ProjectTemplates

Creating Your First Server

Once installed, create a new console application. We will use the standalone console template for this guide, as it is the simplest way to test locally with Claude Desktop or Cursor.

dotnet new mcp-server -n MyFirstMcpServer
cd MyFirstMcpServer

This command generates a project pre-configured with the ModelContextProtocol NuGet package and the necessary hosting setup.

Implementing Tools and Resources

The core of an MCP server consists of Tools (executable functions) and Resources (readable data). The .NET SDK uses attributes to map standard C# methods to these MCP concepts.

Defining a Tool

Create a service class and annotate it with [McpServerTool]. The SDK automatically generates the JSON schema required for the LLM to understand the tool's inputs.

using ModelContextProtocol.Server;
using System.ComponentModel;

[McpServerToolType("WeatherTools", "Tools for retrieving weather data.")]
public class WeatherService
{
    [McpServerTool("Get the current temperature for a city.")]
    public string GetTemperature(
        [Description("The name of the city (e.g., 'New York')")] string city)
    {
        // In a real app, call an external weather API here
        return $"The temperature in {city} is 72°F.";
    }
}

Registering Services

In your Program.cs, register the service with the host builder. The WithToolsFromAssembly() method scans your project for any classes marked with MCP attributes.

var builder = Host.CreateEmptyApplicationBuilder(args);

// Register the MCP server and discover tools
builder.Services.AddMcpServer()
    .WithStdioServerTransport()
    .WithToolsFromAssembly();

var app = builder.Build();
await app.RunAsync();

Choosing a Transport: Stdio vs. SSE

MCP supports two primary transport mechanisms, and your choice depends on where your agent lives.

Standard Input/Output (Stdio)

Best for: Local development, Claude Desktop, Cursor.

Stdio transport runs your executable as a subprocess. Communication happens over standard input and output streams. This is secure by default as it runs entirely on your local machine.

Configuration: builder.Services.AddMcpServer().WithStdioServerTransport();

Server-Sent Events (SSE)

Best for: Remote deployment, shared services, multi-agent systems.

SSE allows your MCP server to run as a web service (e.g., inside an ASP.NET Core API). Clients connect via HTTP to receive updates and send commands. This is ideal for exposing internal microservices to agents running in cloud environments like Fast.io.

Configuration: builder.Services.AddMcpServer().WithSseServerTransport();

Debugging and Logging

Debugging Stdio servers requires care because Console.WriteLine writes to standard output, which is reserved for the MCP protocol itself. Printing random text to stdout will corrupt the JSON-RPC messages and crash the connection.

The Golden Rule of MCP Logging

Always log to Stderr.

In .NET, you can configure your logging provider to write to standard error, or use a file logger. The default ILogger configuration in the MCP templates usually handles this, but be cautious with manual Console calls.

// BAD: Corrupts the protocol
Console.WriteLine("Debug: " + variable);

// GOOD: specific logging or stderr
Console.Error.WriteLine("Debug: " + variable);

Using the MCP Inspector

To test your server without a full agent, use the MCP Inspector web tool. You can run it via npx and point it to your .NET executable to verify that tools strictly match the expected schema.