.NET Debugger for MCP server

DotnetDebugger.Mcp

An MCP server that lets an AI assistant debug .NET programs: launch or attach to a process, set breakpoints, step through code, inspect variables and evaluate expressions. It also carries a searchable reference on how .NET debuggers work internally.

Published on NuGet as DotnetDebugger.Mcp. Built on clrdbg, driven over the Debug Adapter Protocol. The debugger travels inside the package and runs as a child process, so a crash in native debugging code costs the debug session rather than the server.

Origin. A fork of decriptor/SharpDbg.MCP, now far

enough from it to carry 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, launching a program under the

debugger is new, and the two have not shared a commit since. This repository was called

SharpDbg.MCP until the first release; GitHub redirects the old name, and the project files and

SHARPDBG_* settings still carry it.

What it can do

what was thrown

• Attach to a running .NET process, or launch one and stop before its first line executes
• Set breakpoints by file and line or by method name, with conditions and hit counts
• Step over, into and out of code, and read the call stack for any thread
• Inspect local variables, expand objects member by member, and evaluate C# expressions
• Break on exceptions - all of them, only the unhandled ones, or only the types you name - and read

a Mac Catalyst app - building it and stopping before its first line, same as a desktop program

• Read the debuggee's stdout and stderr
• Debug more than one process at once, each with its own breakpoints and stops
• Debug a .NET MAUI app on an Android emulator or phone, an iOS simulator or device, or this Mac as

• Search embedded documentation on ICorDebug, the Debug Adapter Protocol and expression evaluation

What it cannot do

Some of these need changes in the underlying debugger rather than here.

reads the code off a process it started itself and has none for one it was pointed at, so for an attached process there is nothing to report — and the protocol cannot say "unknown", only 0, which would be a number this server made up. A program started with launch_program does report its real code.

• Report the exit code of a process it attached to. exit_code is null there. The debugger

debugger shim cannot find it to load the matching components. The attempt fails immediately with CORDBGEDEBUGCOMPONENTMISSING (0x80131C3C), reported as Attempting to register for runtime startup failed: -2146231236. Self-contained on its own works, and single-file on its own works; only the combination does not.

• Debug a self-contained single-file publish. The runtime is packed inside the executable, so the

• Watch expressions, hot reload and data breakpoints are not implemented.

Requirements

• .NET 10 SDK or later
• An MCP-compatible client, such as Claude Code or Claude Desktop
• Windows, macOS or Linux

Install

One package carries the debugger and its native shims for every platform, so the same configuration works everywhere. There is nothing to clone or build.

Claude Code, for the current project:

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

Add --scope user to make it available in every project, or --scope project to write a .mcp.json that is committed and shared with your team.

Claude Desktop, by editing ~/.config/Claude/claudedesktopconfig.json on macOS and Linux, or %APPDATA%\Claude\claudedesktopconfig.json on Windows:

Shortened. The full README is on GitHub.