DotnetDebugger.Mcp 0.7.1

.NET Debugger for MCP

An MCP server that gives an AI agent a real .NET debugger. It attaches to a running process or launches a program under the debugger, sets line and function breakpoints, steps, reads locals and the call stack, and evaluates expressions in the target — the same operations a developer performs in an IDE, exposed as tools an agent can call.

Built on clrdbg, driven over the Debug Adapter Protocol. The debugger runs as a child process, so a crash in native debugging code costs the debug session rather than the server.

Requirements

The .NET 10 SDK. It provides dnx, and the server itself targets net10.0.

Install

Claude Code:

claude mcp add dotnet-debugger -- dotnet tool exec DotnetDebugger.Mcp --version 0.7.1 --yes

VS Code (.vscode/mcp.json):

{
  "servers": {
    "dotnet-debugger": {
      "type": "stdio",
      "command": "dotnet",
      "args": ["tool", "exec", "DotnetDebugger.Mcp", "--version", "0.7.1", "--yes"]
    }
  }
}

Claude Desktop, or any other client taking JSON:

{
  "mcpServers": {
    "dotnet-debugger": {
      "command": "dotnet",
      "args": ["tool", "exec", "DotnetDebugger.Mcp", "--version", "0.7.1", "--yes"]
    }
  }
}

There is no path to fill in and nothing to clone. The package carries the debugger and its native shims for every platform, so the same configuration works on Windows, macOS and Linux.

dnx DotnetDebugger.Mcp --version 0.7.1 --yes is the equivalent shorter form. Prefer dotnet tool exec in a client launched from a desktop environment: dnx lives in the SDK directory, which such a client often does not have on its PATH, while dotnet reliably is.

The version is pinned on purpose: without --version each start resolves the package again, and a new release would run without anyone having chosen it. Change it in the command to upgrade.

To skip the resolution step, install it once and call the command directly:

dotnet tool install -g DotnetDebugger.Mcp --version 0.7.1

This needs ~/.dotnet/tools on your PATH, which is the reason it is not the default suggestion.

What it exposes

Sessions and processes: list_dotnet_processes, attach_to_process, launch_program, start_program, get_program_output, detach_from_process, list_sessions, close_session.

Breakpoints: set_breakpoint, set_function_breakpoint, remove_breakpoint, list_breakpoints, set_exception_break_mode.

Execution and inspection: continue_execution, pause_execution, step_over, step_into, step_out, wait_for_stop, get_process_status, get_stack_trace, get_threads, get_variables, expand_variable, evaluate_expression, get_exception_info.

.NET MAUI: list_mobile_devices, build_mobile_app, launch_mobile_app — debug an app on an Android emulator or phone, an iOS simulator or device, or this Mac as a Mac Catalyst app, with the same breakpoints and stepping. The remote CoreCLR debugging libraries this needs ship in the package; see the README for what the app has to target.

It also answers questions about .NET debugging internals: search_debugging_concepts, explain_icordebug_interface, get_debugging_flow, list_debugging_concepts.

Configuration

Every setting is optional and read from the environment — timeouts, session limits, Just My Code, diagnostics. They are documented in the full README.

Origin

A fork of decriptor/SharpDbg.MCP, rewritten far enough to warrant its own name: the debugger layer speaks the Debug Adapter Protocol instead of calling a debugger's internal API, the debugger underneath has since changed from SharpDbg to clrdbg, and launching a program under the debugger is new.

MIT licensed. Issues and full documentation: github.com/nevse/dotnet-debugger-mcp.