.NET MCP Server

Give your AI assistant superpowers for .NET development! This MCP server connects GitHub Copilot, Claude, and other AI assistants directly to the .NET SDK, enabling them to create projects, manage packages, run builds, and more—all through natural language.

Quick Install

Click to install in your preferred environment:

Note: Quick install requires .NET 10 SDK.

What is This?

The .NET MCP Server is a Model Context Protocol (MCP) server that connects AI assistants to the .NET SDK using the Model Context Protocol. Think of it as giving your AI assistant a direct line to dotnet commands, but with intelligence and context.

Important: This package is designed exclusively as an MCP server for AI assistants. It is not intended for use as a library or for programmatic consumption in other .NET applications. The only supported use case is running it as an MCP server via dnx or dotnet run.

graph LR
    A[AI Assistant<br/>Copilot/Claude] -->|Natural Language| B[.NET MCP Server]
    B -->|dotnet commands| C[.NET SDK]
    C -->|Results| B
    B -->|Structured Response| A
    
    style A fill:#e1f5ff
    style B fill:#fff4e6
    style C fill:#e8f5e9

Why Use It?

🚀 Faster Development

Instead of remembering exact dotnet commands and syntax, just ask:

• "Create a new web API project with Entity Framework"
• "Add the Serilog package and configure structured logging"
• "Update all my NuGet packages to the latest versions"

🧠 Smarter AI Assistance

Your AI assistant gets direct access to:

• All installed .NET templates and their parameters
• NuGet package search and metadata
• Framework version information (including LTS status)
• Your solution and project structure

⚡ Token-Efficient by Design

Instead of relying on the LLM to infer state by reading and re-reading console output, the server exposes purpose-built .NET tools with structured inputs and outputs. In practice, this typically means fewer tokens per task and less back-and-forth.

• Deterministic tool schemas reduce prompt/response overhead
• machineReadable: true returns structured JSON (no log scraping)
• MCP Resources provide lightweight metadata without running commands

🎯 Why Not Just Let the AI Call dotnet Directly?

The .NET MCP Server provides context and intelligence that raw CLI execution cannot:

1. Template Discovery & Validation

• With MCP: AI knows exactly which templates are installed (console, webapi, blazor, etc.) and their parameters
• Without MCP: AI guesses template names and parameters, often getting them wrong

2. Framework Intelligence

• With MCP: AI knows which .NET versions are installed, which are LTS, and can recommend appropriately
• Without MCP: AI suggests net8.0 when you only have net10.0 installed, leading to errors

3. Rich Tool Descriptions

• With MCP: Each tool has detailed parameter descriptions and constraints (e.g., "configuration must be Debug or Release")
• Without MCP: AI constructs commands from general knowledge, missing version-specific changes

4. Parameter Information

• With MCP: AI sees template parameters like --use-controllers, --auth, framework options
• Without MCP: AI doesn't know what optional parameters exist for each template

5. Package Search Integration

• With MCP: AI can search NuGet.org to find exact package names and versions
• Without MCP: AI guesses package names, often suggesting outdated or incorrect ones

6. Structured Error Handling with Enhanced Diagnostics

• With MCP: Errors are parsed and enriched with explanations, documentation links, and suggested fixes
• Without MCP: AI gets raw stderr output and may misinterpret errors

The server provides enhanced error diagnostics for 52 common error codes:

• Plain English explanations of what went wrong
• Direct links to official Microsoft documentation
• Specific suggested fixes with commands to resolve issues
• Support for CS####, MSB####, NU####, and NETSDK#### error codes

See Error Diagnostics Documentation for details.

7. MCP Resources

MCP Resources provide read-only access to structured metadata about your .NET environment:

• dotnet://sdk-info - Information about installed .NET SDKs (versions and paths)
• dotnet://runtime-info - Information about installed .NET runtimes (versions and types)
• dotnet://templates - Complete catalog of installed .NET templates with metadata
• dotnet://frameworks - Information about supported .NET frameworks (TFMs) including LTS status

This enables AI assistants to:

• Answer questions without executing commands ("What .NET versions do I have installed?")
• Provide context-aware suggestions based on your actual environment
• Access structured JSON data more efficiently than parsing CLI output
• Reference official .NET metadata for accurate recommendations

Example: Using resources for context-aware assistance

❌ Without Resources:
User: "What .NET versions do I have?"
AI: Executes dotnet --list-sdks and parses output
User: "Which is LTS?"
AI: Executes dotnet --info and tries to parse support info

✅ With Resources:
User: "What .NET versions do I have?"
AI: Reads dotnet://sdk-info resource (no execution needed)
    Returns: .NET 8.0 (LTS), .NET 9.0 (STS), .NET 10.0 (LTS)
User: "Which is LTS?"
AI: Already knows from resource metadata - .NET 8.0, .NET 10.0

Example: Creating a Blazor project with authentication

❌ Without MCP:
AI: "I'll run: dotnet new blazor --auth Individual"
Result: Error - template 'blazor' doesn't support --auth parameter

✅ With MCP:
AI: Uses dotnet_sdk with action: "TemplateInfo" for 'blazor'
  Sees available parameters: --interactivity, --use-program-main, --empty
  Uses dotnet_sdk with action: "SearchTemplates" to find authentication templates
AI: "I'll create a Blazor Web App with authentication using the correct template..."
Result: Success - uses 'blazor' template with proper authentication configuration

✨ Consistent Results

The MCP server uses official .NET SDK APIs and CLI commands, ensuring:

• Accurate template information from the Template Engine
• Reliable command execution
• Proper error handling and validation

🔒 Secure by Design

• Runs locally on your machine
• No data sent to external servers
• You control what commands execute
• Standard .NET security model applies
• Automatic secret redaction to protect sensitive information in CLI output
  • Connection strings, passwords, and API keys are automatically redacted
  • Implemented using optimized regular expressions with <1% performance overhead
  • References Microsoft.Extensions.Compliance.Redaction for future integration
  • Opt-out available with unsafeOutput=true for advanced debugging
  • Patterns include: database credentials, cloud provider keys, tokens, certificates, and more
  • Performance impact is minimal and tested to complete within 500ms for 10,000 lines

How It Works

sequenceDiagram
    participant User
    participant AI as AI Assistant
    participant MCP as .NET MCP Server
    participant SDK as .NET SDK

    User->>AI: "Create a console app called MyApp"
    AI->>MCP: dotnet_project(action: "New", template: "console", name: "MyApp")
    MCP->>SDK: dotnet new console -n MyApp
    SDK-->>MCP: Project created successfully
    MCP-->>AI: Structured result with output
    AI-->>User: "I've created a new console app called MyApp"

The .NET MCP Server acts as an intelligent middleware that:

1. Translates natural language requests into structured .NET SDK operations
2. Validates parameters using official SDK metadata (templates, frameworks, packages)
3. Executes commands safely with proper error handling
4. Returns structured results that AI assistants can understand and explain

🧩 MCP C# SDK Features Used

dotnet-mcp uses the official MCP C# SDK and exercises a broad set of MCP features beyond basic tool invocation:

Feature	How dotnet-mcp uses it	Why
Resources	Exposes dotnet://sdk-info, dotnet://runtime-info, dotnet://templates, and dotnet://frameworks as read-only MCP resources.	Lets clients answer environment questions quickly without shelling out, and reduces token churn from repeated CLI discovery.
Prompts	Publishes reusable prompts such as create_new_webapi, add_package_and_restore, and run_tests_with_coverage.	Gives MCP clients guided, discoverable workflows instead of rebuilding common prompt scaffolding from scratch.
Roots	Uses client workspace roots to auto-detect a single project or solution when the user omits an explicit path.	Improves out-of-box behavior in IDE clients and reduces the number of parameters users need to supply.
Sampling	Requests client-mediated LLM summaries for build and test failures when the client supports sampling.	Keeps intelligent diagnostics inside the MCP flow without requiring separate server-side model credentials.
Elicitation	Requests explicit confirmation before destructive actions such as clean and solution removal.	Adds a human-in-the-loop safety check for operations that delete artifacts or mutate project structure.
Progress notifications	Reports start/completion progress for long-running restore, build, test, publish, pack, tool, and workload operations.	Gives clients a better UX for slow operations and makes orchestration easier for agents that surface progress.
Tasks	Registers an IMcpTaskStore and marks dotnet_project with optional task support for long-running operations.	Enables async execution, polling, and cancellation patterns instead of forcing every long-running request to block the session.
Tools and tool metadata	Uses consolidated tools with rich metadata such as titles, categories, priorities, action lists, and task support declarations.	Improves discoverability, routing, and client-side presentation, especially in MCP-aware IDE integrations.
Prompt and resource completion	Implements a completion handler so clients can autocomplete prompt and resource argument values.	Makes guided workflows faster and reduces invalid argument entry in clients that support completion UX.
Icons and server metadata	Configures server-level icons plus per-tool IconSource, title, and descriptive metadata across the consolidated surface.	Helps clients present the server and tool catalog more clearly, especially in visual MCP management UIs.

Installation

Requirements

• For Quick Install: .NET 10 SDK
• For Manual Install: .NET 10 SDK
• Visual Studio Code, Visual Studio 2022 (v17.13+), or Claude Desktop

Option 1: Quick Install (Recommended)

Use the install badges at the top of this page to automatically configure the MCP server in your environment. The server will be downloaded from NuGet.org on first use.

Option 2: Manual Configuration

Follow the instructions below for your specific development environment:

Visual Studio Code

Using Quick Install (recommended - .NET 10 required):

1. Click the VS Code Install badge at the top of this page
2. Or manually add via Command Palette: press Ctrl+Shift+P (or Cmd+Shift+P on macOS), run "GitHub Copilot: Add MCP Server", then enter Name dotnet, Type stdio, Command dnx, and Arguments Community.Mcp.DotNet@1.* --yes.

Manual Configuration (for source builds or custom setups):

Edit your VS Code settings (Ctrl+, or Cmd+,, search for "mcp"):

{
  "github.copilot.chat.mcp.servers": {
    "dotnet": {
      "type": "stdio",
      "command": "dotnet",
      "args": ["run", "--project", "/path/to/dotnet-mcp/DotNetMcp/DotNetMcp.csproj"]
    }
  }
}

📖 Full VS Code MCP documentation

Visual Studio 2022

Requirements: Visual Studio 2022 version 17.13 or later

Using Quick Install (recommended - .NET 10 required):

1. Click the Visual Studio Install badge at the top of this page
2. Or manually add via Options: go to Tools > Options > GitHub Copilot > MCP Servers, click Add, then enter Name dotnet, Type stdio, Command dnx, and Arguments Community.Mcp.DotNet@1.* --yes.

Manual Configuration (for source builds or custom setups):

1. Go to Tools > Options > GitHub Copilot > MCP Servers
2. Click Add
3. Enter:
   • Name: dotnet
   • Type: stdio
   • Command: dotnet
   • Arguments: run --project C:\path\to\dotnet-mcp\DotNetMcp\DotNetMcp.csproj

📖 Full Visual Studio MCP documentation

Claude Desktop

Using DNX (recommended - .NET 10 required):

macOS: Edit ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "dotnet": {
      "command": "dnx",
      "args": ["Community.Mcp.DotNet@1.*", "--yes"]
    }
  }
}

Windows: Edit %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "dotnet": {
      "command": "dnx",
      "args": ["Community.Mcp.DotNet@1.*", "--yes"]
    }
  }
}

Manual Configuration (for source builds or custom setups):

macOS:

{
  "mcpServers": {
    "dotnet": {
      "command": "dotnet",
      "args": ["run", "--project", "/path/to/dotnet-mcp/DotNetMcp/DotNetMcp.csproj"]
    }
  }
}

Windows:

{
  "mcpServers": {
    "dotnet": {
      "command": "dotnet",
      "args": ["run", "--project", "C:\\path\\to\\dotnet-mcp\\DotNetMcp\\DotNetMcp.csproj"]
    }
  }
}

GitHub Copilot coding agent (Repository MCP configuration)

You can also configure this MCP server at the repository level for GitHub Copilot coding agent.

1. Open your repo on GitHub
2. Go to Settings > Copilot > Coding agent
3. Paste the JSON below into the MCP configuration box
4. Click Save

For details, see GitHub's documentation: Extending GitHub Copilot coding agent with the Model Context Protocol (MCP)

{
  "mcpServers": {
    "dotnet": {
      "type": "local",
      "command": "dnx",
      "args": ["Community.Mcp.DotNet@1.*", "--yes"],
      "tools": [
        "dotnet_project",
        "dotnet_package",
        "dotnet_solution",
        "dotnet_sdk",
        "dotnet_help",
        "dotnet_server_capabilities",
        "dotnet_server_info"
      ]
    }
  }
}

This configuration uses a curated allowlist of tools (instead of "*") so the agent can use the .NET MCP server safely and predictably.

Note: Copilot coding agent runs on GitHub Actions runners. If you need to ensure .NET 10 is installed for your repository, add a setup workflow like .github/workflows/copilot-setup-steps.yml.

Usage Examples

Once configured, you can use natural language with your AI assistant:

Quick Start - Single Project

User: "Create a new web API project called WeatherService"

AI: I'll create a new web API project for you...

dotnet new webapi -n WeatherService

The project has been created successfully in the WeatherService directory.

Complex Application - Microservices with Aspire

User: "Create a server-side web app and minimal API, orchestrated by .NET Aspire, with unit tests for the API using xunit. Use slnx format for the solution."

AI: I'll create a complete microservices solution with .NET Aspire orchestration...

# Create solution with new XML format
dotnet new sln -n MyMicroservices --use-slnx

# Create .NET Aspire AppHost for orchestration
dotnet new aspire-apphost -n MyMicroservices.AppHost

# Create web app
dotnet new webapp -n MyMicroservices.Web

# Create minimal API
dotnet new webapi -n MyMicroservices.Api --use-minimal-apis

# Create test project
dotnet new xunit -n MyMicroservices.Api.Tests

# Add projects to solution
dotnet sln add MyMicroservices.AppHost/MyMicroservices.AppHost.csproj
dotnet sln add MyMicroservices.Web/MyMicroservices.Web.csproj
dotnet sln add MyMicroservices.Api/MyMicroservices.Api.csproj
dotnet sln add MyMicroservices.Api.Tests/MyMicroservices.Api.Tests.csproj

# Add project references for tests
dotnet add MyMicroservices.Api.Tests/MyMicroservices.Api.Tests.csproj reference MyMicroservices.Api/MyMicroservices.Api.csproj

Solution created with 4 projects: AppHost for orchestration, Web app, API, and unit tests. Ready to run with dotnet run --project MyMicroservices.AppHost.

Database-Driven Application with Entity Framework

User: "Set up Entity Framework Core with SQL Server for my API and create the initial database migration"

AI: I'll add EF Core packages, install the dotnet-ef tool, and create your initial migration...

# Add Entity Framework packages
dotnet add package Microsoft.EntityFrameworkCore
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
dotnet add package Microsoft.EntityFrameworkCore.Design

# Install dotnet-ef tool globally
dotnet tool install dotnet-ef --global

# Create initial migration
dotnet ef migrations add InitialCreate

# Apply migration to create database
dotnet ef database update

Entity Framework Core with SQL Server provider added. Initial migration created and applied. Database is ready for use.

User: "I added a Product entity to my DbContext. Update the database schema"

AI: I'll create a migration for your Product entity and apply it...

# Create migration for new entity
dotnet ef migrations add AddProductEntity

# List migrations to see what's pending
dotnet ef migrations list

# Apply the migration
dotnet ef database update

Migration created for Product entity (new table with Id, Name, Price, CreatedDate columns). Database updated successfully.

User: "Generate SQL script for the last migration so I can review it before production deployment"

AI: I'll generate an idempotent SQL script from your migration...

# Generate idempotent SQL script (can be run multiple times safely)
dotnet ef migrations script --idempotent --output deploy.sql

SQL script generated to deploy.sql. This script can be safely run multiple times and will only apply changes if needed.

Database-First Development

User: "I have an existing SQL Server database. Reverse engineer it to Entity Framework classes"

AI: I'll scaffold your database into Entity Framework Core entities...

# Reverse engineer (scaffold) database to EF Core entities
dotnet ef dbcontext scaffold "Server=localhost;Database=MyExistingDb;Trusted_Connection=true;" Microsoft.EntityFrameworkCore.SqlServer --output-dir Models

# List the generated DbContext classes
dotnet ef dbcontext list

# Get detailed info about the DbContext
dotnet ef dbcontext info

Database scaffolded successfully. Generated MyExistingDbContext.cs and 15 entity classes (Customer, Order, Product, etc.) in the Models folder.

Multi-Target Testing Strategy

User: "Add integration tests using NUnit that target both .NET 8 and .NET 10, and configure them to run with code coverage"

AI: I'll set up multi-targeted integration tests with coverage...

# Create NUnit test project
dotnet new nunit -n MyMicroservices.IntegrationTests

# Update project to multi-target (edit .csproj)
# <TargetFrameworks>net8.0;net10.0</TargetFrameworks>

# Add integration test packages
dotnet add MyMicroservices.IntegrationTests package Microsoft.AspNetCore.Mvc.Testing
dotnet add MyMicroservices.IntegrationTests package Microsoft.Testing.Extensions.CodeCoverage

# Run tests with coverage for both frameworks
dotnet test -- --coverage --coverage-output-format cobertura

Integration test project created with multi-targeting. Tests will run on both .NET 8 and .NET 10 with code coverage enabled.

Exploring and Discovering

User: "What templates are available for creating cloud-native applications?"

AI: Let me search for cloud-native related templates...

dotnet new search aspire
dotnet new search dapr
dotnet new search azure

Found templates:

• aspire - .NET Aspire Application
• aspire-apphost - .NET Aspire App Host
• aspire-servicedefaults - .NET Aspire Service Defaults
• dapr - Dapr application templates
• Various Azure Functions and Container Apps templates

Each template is designed for cloud-native microservices and distributed applications.

Modernization Workflow

User: "Update all packages to latest versions, format all code to match our editorconfig rules, then build and run tests"

AI: I'll update packages, format code, build, and test...

# Update all packages to latest compatible versions
dotnet package update

# Format all code according to .editorconfig
dotnet format

# Clean and rebuild
dotnet clean
dotnet build -c Release

# Run all tests
dotnet test --verbosity detailed

All packages updated to latest versions. Code formatted consistently across solution. Build succeeded with 0 warnings. All 156 tests passed.

HTTPS Development Setup

User: "I'm getting HTTPS certificate errors when running my web app"

AI: Let me check your HTTPS development certificate...

# Check certificate status
dotnet dev-certs https --check --trust

Your certificate isn't trusted. Let me fix that...

# Trust the certificate (may require elevation)
dotnet dev-certs https --trust

Certificate is now trusted. Try running your app again. If you're using Docker, you can export the certificate:

# Export for Docker containers
dotnet dev-certs https --export-path ./certs/aspnetapp.pfx --password "SecurePassword123!"

Certificate exported to ./certs/aspnetapp.pfx. You can now mount it in your Docker container.

Secure Configuration with User Secrets

User: "Set up user secrets for my API project with a database connection string"

AI: I'll initialize user secrets for your project...

# Initialize user secrets (adds UserSecretsId to project file)
dotnet user-secrets init --project MyApi/MyApi.csproj

Now I'll add your database connection string securely...

# Store connection string (not committed to Git)
dotnet user-secrets set "ConnectionStrings:DefaultConnection" "Server=localhost;Database=MyDb;User=dev;Password=secret123"

Secret stored! You can also add API keys:

# Add Azure OpenAI API key
dotnet user-secrets set "Azure:OpenAI:ApiKey" "sk-..."

# Add SendGrid API key
dotnet user-secrets set "SendGrid:ApiKey" "SG...."

Let me show you what's configured:

# List all secrets
dotnet user-secrets list

Output:

ConnectionStrings:DefaultConnection = Server=localhost;Database=MyDb;User=dev;Password=secret123
Azure:OpenAI:ApiKey = sk-...
SendGrid:ApiKey = SG....

These secrets are stored in your user profile (not in the project) and won't be committed to Git. In your code, access them like:

var connectionString = builder.Configuration["ConnectionStrings:DefaultConnection"];
var apiKey = builder.Configuration["Azure:OpenAI:ApiKey"];

Note: User secrets are for development only. Use Azure Key Vault or environment variables for production.

Mobile and MAUI Development Setup

User: "I want to develop a .NET MAUI app for Android and iOS"

AI: I'll help you set up the necessary workloads for MAUI development...

# First, let's see what MAUI workloads are available
dotnet workload search maui

Found workloads:

Workload ID       Description              
-------------------------------------------
maui-android      .NET MAUI SDK for Android
maui-ios          .NET MAUI SDK for iOS    
maui-windows      .NET MAUI SDK for Windows
maui-tizen        .NET MAUI SDK for Tizen  

Now I'll install the workloads you need:

# Install MAUI workloads for Android and iOS
# Warning: This will download several GB of SDKs and tools
dotnet workload install maui-android maui-ios

Note: The command above shows the raw dotnet CLI syntax, which uses space-separated workload IDs. When calling the .NET MCP workload install tool, pass workload IDs as a single comma-separated parameter, for example: workloadIds: "maui-android,maui-ios". The MCP server will translate this into the equivalent CLI command.

Workloads installed! Let's verify:

# List installed workloads
dotnet workload list

Output:

Installed Workload Id    Manifest Version      Installation Source
----------------------------------------------------------------------
maui-android            10.0.100/10.0.100     SDK 10.0.100        
maui-ios                10.0.100/10.0.100     SDK 10.0.100        

Now you can create a MAUI project:

# Create a new MAUI app
dotnet new maui -n MyMauiApp

Your MAUI development environment is ready! When SDK updates are available, update your workloads:

# Update all installed workloads
dotnet workload update

Available Tools

All tools include visual icons for improved discoverability in AI assistant interfaces. Icons use Microsoft Fluent UI Emoji for consistent visual representation (📁 projects, 📦 packages, ⚙️ SDK, 🛠️ tools, etc.).

The server provides comprehensive .NET development capabilities through consolidated MCP tools that group related operations by domain, making it easier for AI assistants to select the right tool and compose workflows.

Note: The .NET MCP Server uses consolidated tools only. Each consolidated tool provides multiple related operations through an action parameter. This design improves AI orchestration and provides better semantic organization compared to having individual tools for each operation.

MCP Resources (Read-Only Context)

The server exposes read-only resources that provide efficient access to .NET environment metadata:

• dotnet://sdk-info - Information about installed .NET SDKs (versions and paths)
• dotnet://runtime-info - Information about installed .NET runtimes (versions and types)
• dotnet://templates - Complete catalog of installed .NET templates with metadata
• dotnet://frameworks - Information about supported .NET frameworks (TFMs) including LTS status

Resources provide structured JSON data and are more efficient than tool calls for frequently accessed read-only information.

Consolidated Tools

These tools group related operations using action enums, providing better AI orchestration and clearer semantic organization.

dotnet_project - Project Lifecycle Management

Unified interface for all project operations: New, Restore, Build, Run, Test, Publish, Clean, Analyze, Dependencies, Validate, Pack, Watch, Format, Stop, Logs

New in this release:

• Logs action: Retrieve stdout/stderr logs from background process sessions
• Background mode for Run: Start processes in the background with startMode: "Background" and retrieve logs via session ID
• Stop action: Terminates long-running process sessions (like dotnet run) by session ID
• noBuild parameter: Skip building before running (mirrors dotnet run --no-build)

Test Runner Compatibility: The Test action automatically detects the test runner from global.json configuration. If global.json contains { "test": { "runner": "Microsoft.Testing.Platform" } }, it uses the --project flag (MTP mode). Otherwise, it defaults to positional argument (VSTest mode) for legacy compatibility.

You can explicitly specify the test runner using the testRunner parameter:

• Auto (default) - Auto-detect from global.json
• MicrosoftTestingPlatform - Use --project flag (requires .NET SDK 8+ with MTP or SDK 10+)
• VSTest - Use positional argument (compatible with all SDK versions)

The useLegacyProjectArgument parameter is deprecated; use testRunner: "VSTest" instead.

Example:

// Create a new web API project
await callTool("dotnet_project", { 
  action: "New", 
  template: "webapi", 
  name: "MyApi" 
});

// Build the project
await callTool("dotnet_project", { 
  action: "Build", 
  project: "MyApi/MyApi.csproj", 
  configuration: "Release" 
});

// Run in background mode to get session ID
const runResult = await callTool("dotnet_project", {
  action: "Run",
  project: "MyApi/MyApi.csproj",
  noBuild: true,
  startMode: "Background",
  machineReadable: true
});
const sessionId = runResult.metadata.sessionId;

// Wait a moment for the application to start...

// Retrieve logs from the background session
await callTool("dotnet_project", {
  action: "Logs",
  sessionId: sessionId,
  machineReadable: true
});

// Retrieve only the last 50 lines of logs
await callTool("dotnet_project", {
  action: "Logs",
  sessionId: sessionId,
  tailLines: 50,
  machineReadable: true
});

// Retrieve logs since a specific timestamp
await callTool("dotnet_project", {
  action: "Logs",
  sessionId: sessionId,
  since: "2024-01-01T12:00:00Z",
  machineReadable: true
});

// Stop the background process
await callTool("dotnet_project", {
  action: "Stop",
  sessionId: sessionId
});

// Run tests (auto-detects test runner from global.json)
await callTool("dotnet_project", { 
  action: "Test", 
  project: "MyApi.Tests/MyApi.Tests.csproj" 
});

// Run tests with explicit test runner (MTP)
await callTool("dotnet_project", { 
  action: "Test", 
  project: "MyApi.Tests/MyApi.Tests.csproj",
  testRunner: "MicrosoftTestingPlatform"
});

// Run tests with explicit test runner (VSTest)
await callTool("dotnet_project", { 
  action: "Test", 
  project: "MyApi.Tests/MyApi.Tests.csproj",
  testRunner: "VSTest"
});

dotnet_package - Package and Reference Management

Manage NuGet packages and project references: Add, Remove, Search, Update, List, AddReference, RemoveReference, ListReferences, ClearCache

Example:

// Search for a package
await callTool("dotnet_package", { 
  action: "Search", 
  searchTerm: "serilog" 
});

// Add package to project
await callTool("dotnet_package", { 
  action: "Add", 
  packageId: "Serilog.AspNetCore", 
  project: "MyApi/MyApi.csproj" 
});

dotnet_solution - Solution File Management

Full parity with dotnet sln / dotnet solution CLI commands.

Manage solution files and project membership: Create, Add, List, Remove

Examples:

// Create a solution (classic .sln format)
await callTool("dotnet_solution", { 
  action: "Create", 
  name: "MyApp"
});

// Create a solution (new .slnx XML format)
await callTool("dotnet_solution", { 
  action: "Create", 
  name: "MyApp", 
  format: "slnx" 
});

// Add projects to solution
await callTool("dotnet_solution", { 
  action: "Add", 
  solution: "MyApp.slnx", 
  projects: ["MyApi/MyApi.csproj", "MyWeb/MyWeb.csproj"] 
});

// List projects in solution
await callTool("dotnet_solution", { 
  action: "List", 
  solution: "MyApp.slnx"
});

// Remove projects from solution
await callTool("dotnet_solution", { 
  action: "Remove", 
  solution: "MyApp.slnx", 
  projects: ["MyWeb/MyWeb.csproj"] 
});

dotnet_ef - Entity Framework Core Operations

Database migrations, DbContext management, and scaffolding: MigrationsAdd, MigrationsList, MigrationsRemove, MigrationsScript, DatabaseUpdate, DatabaseDrop, DbContextList, DbContextInfo, DbContextScaffold

Example:

// Create a migration
await callTool("dotnet_ef", { 
  action: "MigrationsAdd", 
  name: "InitialCreate", 
  project: "MyApi/MyApi.csproj" 
});

// Update database
await callTool("dotnet_ef", { 
  action: "DatabaseUpdate", 
  project: "MyApi/MyApi.csproj" 
});

dotnet_workload - Workload Management

Install and manage .NET workloads (MAUI, WASM, etc.): List, Info, Search, Install, Update, Uninstall

Example:

// Search for workloads
await callTool("dotnet_workload", { 
  action: "Search", 
  searchTerm: "maui" 
});

// Install workloads
await callTool("dotnet_workload", { 
  action: "Install", 
  workloadIds: "maui-android,maui-ios" 
});

dotnet_tool - .NET Tool Management

Manage global and local .NET tools: Install, List, Update, Uninstall, Restore, CreateManifest, Search, Run

Example:

// Install a tool globally
await callTool("dotnet_tool", { 
  action: "Install", 
  packageId: "dotnet-ef", 
  global: true 
});

// Search for tools
await callTool("dotnet_tool", { 
  action: "Search", 
  searchTerm: "format" 
});

dotnet_sdk - SDK and Template Information

Query SDK, runtime, template, and framework information: Version, Info, ListSdks, ListRuntimes, ListTemplates, SearchTemplates, TemplateInfo, ListTemplatePacks, InstallTemplatePack, UninstallTemplatePack, ClearTemplateCache, FrameworkInfo, CacheMetrics

Example:

// Get SDK version
await callTool("dotnet_sdk", { 
  action: "Version" 
});

// List available templates
await callTool("dotnet_sdk", { 
  action: "ListTemplates" 
});

// Search for templates
await callTool("dotnet_sdk", { 
  action: "SearchTemplates", 
  searchTerm: "web" 
});

// List installed template packs
await callTool("dotnet_sdk", {
  action: "ListTemplatePacks"
});

// Install a template pack (NuGet package ID + version)
await callTool("dotnet_sdk", {
  action: "InstallTemplatePack",
  templatePackage: "Aspire.ProjectTemplates",
  templateVersion: "13.1.0"
});

// Uninstall a template pack
await callTool("dotnet_sdk", {
  action: "UninstallTemplatePack",
  templatePackage: "Aspire.ProjectTemplates"
});

dotnet_dev_certs - Developer Certificates and Secrets

Manage HTTPS certificates and user secrets: CertificateTrust, CertificateCheck, CertificateClean, CertificateExport, SecretsInit, SecretsSet, SecretsList, SecretsRemove, SecretsClear

Example:

// Trust development certificate
await callTool("dotnet_dev_certs", { 
  action: "CertificateTrust" 
});

// Set a user secret
await callTool("dotnet_dev_certs", { 
  action: "SecretsSet", 
  key: "ConnectionStrings:DefaultConnection", 
  value: "Server=localhost;Database=MyDb", 
  project: "MyApi/MyApi.csproj" 
});

Utility Tools

• dotnet_help - Get help for any dotnet command
• dotnet_server_capabilities - Get MCP server capabilities and concurrency guidance

Building from Source

For development or contributing:

git clone https://github.com/jongalloway/dotnet-mcp.git
cd dotnet-mcp
dotnet build --project DotNetMcp/DotNetMcp.csproj

Run the server:

dotnet run --project DotNetMcp/DotNetMcp.csproj

The server communicates via stdio transport and is designed to be invoked by MCP clients.

Project Structure

This project has grown beyond the point where a complete file-by-file listing stays useful. Instead, this section highlights the key entry points and the main areas of the repo.

dotnet-mcp/
├── DotNetMcp/                  # Main MCP server project (packed as a .NET tool)
│   ├── Program.cs              # Hosting + MCP server wiring
│   ├── DotNetMcp.csproj        # NuGet/package metadata (PackAsTool, server.json packing)
│   ├── .mcp/server.json        # MCP server metadata (packed into the NuGet package)
│   ├── Resources/              # MCP resources (SDK/runtime/templates/frameworks)
│   ├── DotNetCliTools.cs       # Tool surface area (split into partials in Tools/)
│   └── Tools/                  # Tool implementations grouped by domain (project, package, EF, etc.)
├── DotNetMcp.Tests/            # Unit + integration tests
├── doc/                        # Long-form documentation (architecture, concurrency, testing, etc.)
├── scripts/                    # Maintenance & validation scripts
├── artifacts*/                 # Build outputs (CI + local)
├── .github/                    # CI workflows and repo automation
├── DotNetMcp.slnx              # Solution file (.slnx)
├── global.json                 # SDK pinning for consistent builds
├── .config/dotnet-tools.json   # Local tool manifest (dotnet local tools)
└── LICENSE                     # MIT License

Key files to start with:

• DotNetMcp/Program.cs - server startup and registration
• DotNetMcp/DotNetCliTools.cs and DotNetMcp/Tools/ - MCP tool implementations
• DotNetMcp/Resources/DotNetResources.cs - read-only MCP resources
• DotNetMcp/.mcp/server.json - packaged MCP server metadata
• DotNetMcp.Tests/ - tests (including server.json validation and XML doc coverage)

Technology Stack

• Protocol: Model Context Protocol (MCP)
• SDK: MCP SDK for .NET v1.0.0
• Runtime: .NET 10.0 (target framework)
• Transport: stdio (standard input/output)
• NuGet Packages:
  • Microsoft.TemplateEngine.Abstractions & Edge (v10.0.101) - Template metadata
  • Microsoft.Build.Utilities.Core & Microsoft.Build (v18.0.2) - Project validation

Documentation

• 📖 CHANGELOG - Version history and release notes
• 📖 AI Assistant Best Practices Guide - Workflows, prompts, integration patterns, and troubleshooting
• 📖 Machine-Readable JSON Contract - v1.0 stable contract for programmatic tool consumption
• 📖 Tool Surface Consolidation - Consolidated tool design and architecture
• 📖 Telemetry and Observability - Request duration logging, OpenTelemetry integration, and performance monitoring
• 📖 SDK Integration Details - Technical architecture and SDK usage
• 📖 Advanced Topics - Performance, logging, and security details
• 📖 Releasing - How to cut a release (checklists + scripts)
• 📖 Concurrency Safety - Parallel execution guidance for AI orchestrators
• 📖 Testing - How to run tests (including opt-in interactive tests)
• 📖 Model Context Protocol - Official MCP specification
• 📖 MCP C# SDK Docs - SDK documentation

Interoperability

The .NET MCP Server follows the Model Context Protocol specification and provides rich metadata for tool discovery and AI orchestration:

Server Metadata

The server includes an MCP Registry server.json configuration file (.mcp/server.json) that provides:

• Environment Variables: Optimized .NET CLI settings for MCP usage

  • DOTNET_SKIP_FIRST_TIME_EXPERIENCE=1 - Skips first-time setup
  • DOTNET_NOLOGO=1 - Suppresses startup messages

• Package Information: NuGet package details for easy installation via dnx (requires .NET 10)

  • Package: Community.Mcp.DotNet
  • Registry: NuGet.org
  • Transport: stdio

• Repository Information: Links back to the source repo

Tool and resource metadata is discovered at runtime via the MCP protocol (tool/resource listing), using XML docs and [McpMeta] attributes in the server code.

Tool Namespacing

All tools use the dotnet_ prefix in their external IDs to prevent naming collisions with other MCP servers. This follows best practices for MCP server interoperability:

Examples:

• dotnet_project - Project lifecycle operations (create/build/test/run/publish)
• dotnet_package - NuGet packages and project references
• dotnet_solution - Solution operations
• dotnet_sdk - SDK/runtime/template/framework metadata

Discovery Metadata

Tool discovery metadata (categories, tags, commonly-used hints) is provided via [McpMeta] attributes and surfaced through MCP tool listing.

Metadata Access

AI orchestrators can access server metadata through:

1. MCP Protocol: Standard tool/resource listing via MCP SDK
2. server.json: Static metadata file for registration and discovery
3. Tool Attributes: Runtime metadata via McpMeta attributes in code

For detailed integration examples, see the MCP specification and our SDK integration documentation.

Contributing

Contributions are welcome! This is a community-maintained project.

Ways to contribute:

• 🐛 Report bugs or request features via GitHub Issues
• 💡 Submit pull requests for new tools or improvements
• 📝 Improve documentation
• ⭐ Star the repo to show support

Development setup:

1. Fork the repository
2. Clone your fork
3. Create a feature branch
4. Make your changes
5. Test thoroughly
6. Submit a pull request

See .github/copilot-instructions.md for development guidelines.

Troubleshooting

"dnx not found"

• Cause: .NET 10 SDK not installed
• Solution: Install .NET 10 SDK or use manual configuration with dotnet run

"No templates found"

• Cause: .NET SDK templates not installed
• Solution: Run dotnet new --install to install default templates

"Server not responding"

• Cause: Server crashed or failed to start
• Solution: Check logs in your MCP client, ensure .NET SDK is in PATH

"Unrecognized option '--project'" or "Unknown switch" when running tests

• Cause: Test runner mismatch or SDK version incompatibility
• Background: The --project flag is only supported by Microsoft Testing Platform (MTP). The legacy VSTest runner uses positional arguments instead.
• Solution: The MCP server now auto-detects the test runner from global.json:
  1. Auto mode (default): Add { "test": { "runner": "Microsoft.Testing.Platform" } } to global.json if using MTP, otherwise it defaults to VSTest
  2. Explicit mode: Set testRunner: "MicrosoftTestingPlatform" or testRunner: "VSTest" when calling dotnet_project Test action
  3. Legacy parameter: Use useLegacyProjectArgument: true (deprecated, use testRunner: "VSTest" instead)
• Verify support: Run dotnet test --help | grep -- --project to check if your SDK supports the --project flag
• More info: See doc/testing.md for detailed test runner compatibility and troubleshooting
• References: dotnet test overview | MTP | VSTest

Need Help?

• 📖 Check the documentation
• 💬 Open a GitHub Issue
• 🔍 Search existing issues

Related Microsoft MCPs

This .NET MCP server focuses on .NET SDK operations (build, run, test, templates, SDK management). For specialized scenarios, consider these complementary official Microsoft MCP servers:

• NuGet MCP Server - Advanced NuGet package search, metadata, and automation scenarios beyond basic package management
• Aspire MCP Server - Runtime monitoring, telemetry, distributed tracing, and resource management for .NET Aspire applications

These MCPs work alongside the .NET MCP to provide comprehensive coverage of the .NET development lifecycle:

Feature	.NET MCP	NuGet MCP	Aspire MCP
Primary Focus	.NET SDK operations	Package metadata/discovery	Runtime monitoring
Scope	CLI commands (build, run, test)	NuGet search & automation	Aspire app telemetry
Stage	Development time	Development/discovery time	Runtime/production
Example Operations	dotnet build, dotnet new	Package search, READMEs	Log viewing, tracing

License

MIT License - see LICENSE file for details.