mcp-windbg: Driving CDB and KD From an MCP Client
Model Context Protocol for WinDbg.
At a glance
- What is it?
- svnscha/mcp-windbg is an MIT-licensed Python MCP server that wraps cdb.exe and kd.exe so an LLM can run real debugger commands against crash dumps, live user-mode targets and kernel targets. The useful part is the session layer; the constraint is that everything depends on a Windows debugging host and on the model's willingness to run the right command.
- Who is it for?
- Adopt it if you already keep a Windows box with the Debugging Tools for Windows and want dump triage or live attaching driven from an MCP client such as Claude Code or GitHub Copilot. Skip it if your crashes are Linux core files, or if you need the debugging host to be Linux, since the server drives cdb.exe and kd.exe only.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap mcp-windbg fills between a dump file and a chat window
Crash dump triage is a sequence of small, well-known steps: pick the dump, load symbols, run !analyze -v, read the faulting frame, list modules and threads. People who do it often have aliases and scripts for it. People who do it twice a year open WinDbg, wait, and try to remember the syntax. The README frames the project as a bridge between AI models and WinDbg, and the phrasing it uses for the goal is debugging in natural language, with example prompts like asking for a call stack explanation of an access violation. The audience is therefore narrow and specific: Windows engineers who already own the debugging toolchain and want an assistant to issue the commands and summarise the output. The README is explicit that this is not a magical auto-fix, describing the server instead as a Python wrapper around cdb.exe and kd.exe that lets an LLM run real debugger commands and reason about the output. That sentence sets the expectation correctly. The model is not doing the debugging; it is typing into a debugger you could have typed into yourself.
Two debuggers, one session id per open call
The architecture splits by target type. User-mode work runs under cdb.exe, covering both dump files and remote debug servers reached with -remote over TCP, a named pipe or COM. Kernel work runs under kd.exe, reached with -k over KDNET, a named pipe or serial. Every open_* tool returns an opaque session identifier, and the README gives the shape as cdb-1a2b3c4d. That identifier is the whole coordination mechanism: you pass it to the matching run_*, close_*, send_ctrl_break and wait_for_break calls. Several sessions can be open at once, so a dump from one incident and a live kernel session on a test VM do not collide. The tool list is small and maps cleanly onto the split: list_dumps, open_cdb_dump, open_cdb_remote, open_kd_session, run_cdb_command, run_kd_command, close_cdb_session, close_kd_session, send_ctrl_break, wait_for_break. Ten tools, no ambiguity about which one targets which debugger. The live-session design is the part worth reading twice. The README states that a slow live command which outruns its per-call timeout is interrupted with CTRL+BREAK and the session is resynchronised rather than left wedged. That is a real mechanism, not a marketing line, and it addresses the failure mode you would otherwise hit constantly: a target that was resumed with g and never comes back.
Installing it: uvx plugin, manual registration, or HTTP
The shortest documented route assumes Claude Code and uv. Two commands add a marketplace and install the server plugin: /plugin marketplace add svnscha/mcp-windbg followed by /plugin install mcp-windbg-uvx@mcp-windbg. That plugin launches the server through uvx, which fetches a pinned build from PyPI on first use. uv itself comes from winget install astral-sh.uv. The README lists three plugin variants: mcp-windbg-uvx for the server alone, mcp-windbg-skills which adds four optional skills, and mcp-windbg-agents which adds a crash-analyst agent. The README's own note about enterprise environments is the detail most likely to bite. When managed settings define allowedMcpServers, plugin-bundled MCP servers may be silently skipped, and the recommended workaround is to install and register the server manually and then optionally add the skills or agents plugin. The server still has to be permitted by the organisation's MCP policy. Prerequisites are Windows plus the Debugging Tools for Windows or the Microsoft Store build of WinDbg, which ship cdb.exe and kd.exe; the README says these are auto-detected. Python is described as not a prerequisite in itself, because each install route states its own requirements. For non-local use, the server can run over stdio or as a streamable-HTTP service driven from another machine. There is also a --filter-script hook that can redact PII or secrets from tool arguments and output before they leave the machine, which matters if dumps contain user data.
What it does not do, and where it is the wrong tool
The dependency on Windows is not incidental. The server drives cdb.exe and kd.exe, and the README's platform badge is Windows only. A Linux crash, a macOS crash, or a core file produced by a non-Windows process is outside the design. The same applies to any workflow where the debugging host must be Linux, because there is no documented path in which the server talks to a remote WinDbg engine from a Linux machine; the HTTP option moves the client, not the debugger. The second limitation is epistemic rather than technical. Because the model composes the commands, the quality of a session depends on it choosing kb rather than a command that returns nothing useful, and the README does not claim to validate the model's reasoning. The third is the plugin path itself: the enterprise note means a team can install the plugin, see no error, and still have no tools available, which is a confusing first experience if you do not read that note. Finally, the README does not document a symbol server configuration in the material available here beyond saying the uvx plugin preconfigures symbols, so if your dumps need a private symbol path, verify where that is set before assuming it is handled.
How this differs from scripting cdb.exe yourself
The obvious alternative is a .cmd or Python script that shells out to cdb.exe with a fixed command list and pipes the output to a file. That approach is deterministic and reproducible, which the MCP route is not: the same dump can produce different command sequences on different runs. The script is also faster, because it does not round-trip through a model. What the MCP server adds is adaptivity. After !analyze -v names a faulting module, a model can decide to run lm on that module, then !heap, then a stack on a specific thread, without anyone having written that branch in advance. The session model is what makes this possible: a script exits after its command list, while the server keeps the dump or live target open under a session id and accepts further commands. The trade-off is that you are paying for a model turn to get what a one-line alias would have given you, so for a dump type you see every day, the script wins. For the dump you see twice a year, the server is the more useful of the two.
Maintenance, licence and the cost of following the project
The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence with no copyleft obligation, and it is the same licence the repository badge displays. This is not legal advice; if you ship the server inside a product, have your own counsel read the LICENSE file rather than a review. On maintenance, the release history shows v1.2.1, v1.2.2 and v1.3.0 within roughly two weeks in late August and early September 2026, and the default branch is develop rather than main, which suggests work lands on develop first. The practical cost of adopting this is not the code, it is the host: you need a Windows machine with the debugging tools installed, symbols configured, and network reachability if you use the HTTP mode. The upgrade path through the plugin is a pinned PyPI fetch, so a new release does not reach you until you reinstall or the pin moves. If you register the server manually, you own that upgrade step yourself. Budget for the Windows host and for someone who knows what a good !analyze -v output looks like, because the model will not tell you when it has run the wrong command.
Editorial conclusion
Adopt it if you already keep a Windows box with the Debugging Tools for Windows and want dump triage or live attaching driven from an MCP client such as Claude Code or GitHub Copilot. Skip it if your crashes are Linux core files, or if you need the debugging host to be Linux, since the server drives cdb.exe and kd.exe only. Verify first that cdb.exe and kd.exe are detected on the host, that your client actually sees the ten tools after registration, and what your organisation's MCP policy permits, because the README notes that plugin-bundled servers can be skipped under managed allowedMcpServers settings.
Community notes