.NET MCP Server

.NET MCP Server

[Build and Test] [Coverage] [Dependabot] [NuGet] [Published to MCP Registry] [CodeQL Advanced]

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: [VS Code - Install .NET MCP] [VS Code Insiders - Install .NET MCP] [Visual Studio - Install .NET MCP]

Note: Quick install requires the .NET 10 or .NET 11 SDK. Source builds require .NET 11 RC3 or a compatible GA SDK in the 11.0.1xx feature band.

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
• dotnet://workspace - Workspace snapshot with solution, projects, target frameworks, and package counts

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 outputUser: "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 templatesAI: "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
• Optional MCP governance controls (preview)
  • Uses Microsoft.AgentGovernance.Extensions.ModelContextProtocol when enabled via configuration
  • Disabled by default to preserve existing behavior and compatibility
  • Does not ship with a default enforced policy; provide your own policy file(s) when needed
  • See doc/mcp-governance.md for a sample mcp.yaml policy template
  • Sources:
    • Agent Governance Toolkit repository: https://github.com/microsoft/agent-governance-toolkit
    • Agent Governance Toolkit for .NET: https://github.com/microsoft/agent-governance-toolkit/tree/main/agent-governance-dotnet
    • Announcement: https://devblogs.microsoft.com/dotnet/announcing-agent-governance-toolkit-mcp-extensions-for-dotnet/
  • Startup scanning, policy-based tool authorization, and response sanitization can be enabled with:

"McpGovernance": {  "Enabled": true,  "DefaultAgentId": "did:mcp:anonymous",  "ServerName": "dotnet-mcp",  "PolicyPaths": ["/path/to/your/policies/mcp.yaml"]}

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:

The server uses SDK 2.3.0, supports protocol 2026-07-28, and retains older stdio clients, including 2025-11-25. Async execution requires the new Tasks extension and per-request opt-in; legacy clients continue to call tools inline. See SDK compatibility for wire-protocol differences and governance configuration for the existing fail-closed catalog limitation.

Use dotnet_server_capabilities to discover the negotiated protocol and feature availability for the active request. On 2026-07-28, logging needs a per-request log level, and Sampling/Elicitation depend on the request's client capability metadata. These flags do not carry over from earlier requests. A no-connection snapshot reports implementation support, not a guarantee that a client can use each feature; see the capability contract.

Installation

Requirements

• For package installation: .NET 10 SDK or .NET 11 SDK (RC3 or later)
• For source builds: .NET SDK 11.0.100-rc.3.26522.148 or a GA/servicing SDK in the 11.0.1xx feature band; global.json selects the latest installed compatible patch. Install the .NET 10 SDK alongside it to run both test targets.
• Visual Studio Code, Visual Studio 2022 (v17.13+), or Claude Desktop

Runtime and SDK compatibility

One package contains net10.0 and net11.0 builds with the same MCP tool surface. .NET 10-only machines remain supported. The .NET 11 build uses RC3 Template Engine and Hosting packages; this does not add new .NET 11-only tools or change the default .NET 10 LTS project recommendation.

Tool asset selection follows the SDK used to install or launch the tool, not simply the highest runtime installed. A global.json can select an older SDK. Installing .NET 11 later does not retarget an existing .NET 10 tool installation; reinstall or update it using the desired SDK. For an explicit tool installation target, dotnet tool install also supports --framework net11.0.

Both dnx and a tool-path install were exercised against the same package on isolated .NET 10, RC3, and side-by-side installations. Neither required --allow-roll-forward. For a specific package version, use:

dnx Community.Mcp.DotNet@<exact-version> --yesdotnet tool install Community.Mcp.DotNet@<exact-version> --tool-path ./tools

Replace <exact-version> with the desired published version. An exact prerelease version does not require --prerelease; floating prerelease selection does. Point MCP clients at the installed dotnet-mcp executable when using a tool-path install.

The package explicitly uses RollForward=Minor, keeping runtime resolution within the target major version. The RC3-built package's .NET 11 runtime floor is 11.0.0-rc.3.26522.148. RC3-to-GA is a same-major runtime transition, not a reason to require Major roll-forward. A compatible runtime must already be installed; roll-forward does not download one. CI automatically installs the GA SDK when published and verifies an unchanged RC3-built package on GA, while retaining exact-RC3 coverage. GA execution is pending until GA is available. A .NET 11-only build cannot run backward on .NET 10; the separate .NET 10 assets provide that support.

The server runtime and the SDK used for project commands are separate choices. Future SDK-specific CLI features should be checked against the selected project's SDK; only features using .NET 11-only in-process APIs need the .NET 11 server build.

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", "--framework", "net11.0", "--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 --framework net11.0 --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", "--framework", "net11.0", "--project", "/path/to/dotnet-mcp/DotNetMcp/DotNetMcp.csproj"]    }  }}

Windows:

{  "mcpServers": {    "dotnet": {      "command": "dotnet",      "args": ["run", "--framework", "net11.0", "--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 formatdotnet new sln -n MyMicroservices --use-slnx
# Create .NET Aspire AppHost for orchestrationdotnet new aspire-apphost -n MyMicroservices.AppHost
# Create web appdotnet new webapp -n MyMicroservices.Web
# Create minimal APIdotnet new webapi -n MyMicroservices.Api --use-minimal-apis
# Create test projectdotnet new xunit -n MyMicroservices.Api.Tests
# Add projects to solutiondotnet sln add MyMicroservices.AppHost/MyMicroservices.AppHost.csprojdotnet sln add MyMicroservices.Web/MyMicroservices.Web.csprojdotnet sln add MyMicroservices.Api/MyMicroservices.Api.csprojdotnet sln add MyMicroservices.Api.Tests/MyMicroservices.Api.Tests.csproj
# Add project references for testsdotnet 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 packagesdotnet add package Microsoft.EntityFrameworkCoredotnet add package Microsoft.EntityFrameworkCore.SqlServerdotnet add package Microsoft.EntityFrameworkCore.Design
# Install dotnet-ef tool globallydotnet tool install dotnet-ef --global
# Create initial migrationdotnet ef migrations add InitialCreate
# Apply migration to create databasedotnet 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 entitydotnet ef migrations add AddProductEntity
# List migrations to see what's pendingdotnet ef migrations list
# Apply the migrationdotnet 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 entitiesdotnet ef dbcontext scaffold "Server=localhost;Database=MyExistingDb;Trusted_Connection=true;" Microsoft.EntityFrameworkCore.SqlServer --output-dir Models
# List the generated DbContext classesdotnet ef dbcontext list
# Get detailed info about the DbContextdotnet 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 projectdotnet new nunit -n MyMicroservices.IntegrationTests
# Update project to multi-target (edit .csproj)# <TargetFrameworks>net8.0;net10.0</TargetFrameworks>
# Add integration test packagesdotnet add MyMicroservices.IntegrationTests package Microsoft.AspNetCore.Mvc.Testingdotnet add MyMicroservices.IntegrationTests package Microsoft.Testing.Extensions.CodeCoverage
# Run tests with coverage for both frameworksdotnet 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 aspiredotnet new search daprdotnet 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 versionsdotnet package update
# Format all code according to .editorconfigdotnet format
# Clean and rebuilddotnet cleandotnet build -c Release
# Run all testsdotnet 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 statusdotnet 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 containersdotnet 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 keydotnet user-secrets set "Azure:OpenAI:ApiKey" "sk-..."
# Add SendGrid API keydotnet user-secrets set "SendGrid:ApiKey" "SG...."

Let me show you what's configured:

# List all secretsdotnet user-secrets list

Output:

ConnectionStrings:DefaultConnection = Server=localhost;Database=MyDb;User=dev;Password=secret123Azure: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 availabledotnet workload search maui

Found workloads:

Workload ID       Description              -------------------------------------------maui-android      .NET MAUI SDK for Androidmaui-ios          .NET MAUI SDK for iOS    maui-windows      .NET MAUI SDK for Windowsmaui-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 toolsdotnet 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 workloadsdotnet 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 appdotnet new maui -n MyMauiApp

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

# Update all installed workloadsdotnet 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: Domain tools group related operations through an action parameter. Additive, restricted query companions let clients distinguish verified read-only requests using standard MCP annotations; all existing consolidated calls remain supported.

Read-Only Query Tools

Prefer these tools for qualifying queries:

These tools explicitly advertise read-only, idempotent, closed-world hints and reject other actions at runtime. The eight mixed domain tools retain conservative mutating/open-world hints, while metrics resets are mutating but closed-world. dotnet_help is also conservative because free-form help commands can invoke external tools or CLI initialization.

Not every List, Info, or Search action qualifies: CLI initialization can modify SDK/certificate state, EF discovery can execute application code, and project analysis evaluates MSBuild. Read-only is not synonymous with offline, and annotations are hints rather than permissions or a sandbox. See annotation rationale and action eligibility.

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
• dotnet://workspace - Workspace snapshot with solution, projects, target frameworks, and package counts

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 projectawait callTool("dotnet_project", {   action: "New",   template: "webapi",   name: "MyApi" });
// Build the projectawait callTool("dotnet_project", {   action: "Build",   project: "MyApi/MyApi.csproj",   configuration: "Release" });
// Run in background mode to get session IDconst 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 without invoking a mutating toolawait callTool("dotnet_project_query", {  action: "Logs",  sessionId: sessionId});
// Retrieve only the last 50 lines of logsawait callTool("dotnet_project_query", {  action: "Logs",  sessionId: sessionId,  tailLines: 50});
// Retrieve logs since a specific timestampawait callTool("dotnet_project_query", {  action: "Logs",  sessionId: sessionId,  since: "2024-01-01T12:00:00Z"});
// Stop the background processawait 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 packageawait callTool("dotnet_package", {   action: "Search",   searchTerm: "serilog" });
// Add package to projectawait 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 solutionawait callTool("dotnet_solution", {   action: "Add",   solution: "MyApp.slnx",   projects: ["MyApi/MyApi.csproj", "MyWeb/MyWeb.csproj"] });
// List projects in solutionawait callTool("dotnet_solution", {   action: "List",   solution: "MyApp.slnx"});
// Remove projects from solutionawait 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 migrationawait callTool("dotnet_ef", {   action: "MigrationsAdd",   name: "InitialCreate",   project: "MyApi/MyApi.csproj" });
// Update databaseawait 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 workloadsawait callTool("dotnet_workload", {   action: "Search",   searchTerm: "maui" });
// Install workloadsawait 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 globallyawait callTool("dotnet_tool", {   action: "Install",   packageId: "dotnet-ef",   global: true });
// Search for toolsawait 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 versionawait callTool("dotnet_sdk", {   action: "Version" });
// List available templatesawait callTool("dotnet_sdk", {   action: "ListTemplates" });
// Search for templatesawait callTool("dotnet_sdk", {   action: "SearchTemplates",   searchTerm: "web" });
// List installed template packsawait 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 packawait 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 certificateawait callTool("dotnet_dev_certs", {   action: "CertificateTrust" });
// Set a user secretawait 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:

Install the RC3 baseline SDK from global.json or a GA/servicing SDK in the 11.0.1xx feature band. The latestPatch SDK policy automatically selects the latest compatible installed SDK without crossing feature bands or major versions; CI installs the selected release automatically. The repository's NuGet.Config adds Microsoft's public dotnet-tools feed because Template Engine RC3 depends on NuGet 8.0.0-rc.2448 packages that are not yet on NuGet.org. Retain your normal NuGet.org source for the other dependencies; this extra feed is needed to build, not to install the tool's bundled dependencies. The tool still requires a compatible .NET runtime.

git clone https://github.com/jongalloway/dotnet-mcp.gitcd dotnet-mcpdotnet build "$PWD/DotNetMcp/DotNetMcp.csproj"

Run the server:

dotnet run --framework net11.0 --project DotNetMcp/DotNetMcp.csproj

Choose --framework net10.0 instead to run the .NET 10 build. dotnet run requires an explicit framework for this multi-targeted project. Package consumers do not need the RC3 build SDK to run the .NET 10 assets.

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 v2.3.0, with matching Tasks and Apps extensions
• Runtime: .NET 10.0 and .NET 11.0 RC3 (dual-targeted tool)
• Transport: stdio (standard input/output)
• NuGet Packages:
  • Microsoft.TemplateEngine.Abstractions & Edge (v10.0.403 for .NET 10; v11.0.100-rc.3.26522.148 for .NET 11) - Template metadata
  • Microsoft.Build.Utilities.Core & Microsoft.Build (v18.9.6) - 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 the .NET 10 or .NET 11 SDK. Source-based manual configuration additionally requires an SDK compatible with the RC3 minimum in global.json and an explicit --framework.

"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:

License

MIT License - see LICENSE file for details.