Windbg MCP Server

Windbg MCP server is a locally run integration for AI assistants that speak the Model Context Protocol. WinDbg/DbgEng over MCP: crash dumps, live user & kernel, driver IOCTLs, and TTD.

What you get

An MCP server that exposes WinDbg/DbgEng to AI agents (Claude Code, Claude Desktop, Cursor, …) over stdio. It drives a live debugger engine for user-mode, kernel-mode, crash-dump, and Time Travel Debugging (TTD) workflows.

Setting it up

Setup follows the usual MCP pattern — install or clone the server, register it in your client's configuration file, restart the client.

What the assistant can call

Once Windbg is connected, these are the calls the assistant has available:

• Group — Tools
• Session — open_dump, open_trace, attach_kernel_local, attach_kernel, attach_process, launch, end_session, session_status
• State — registers, read_memory, backtrace, modules, threads, disassemble, dx
• Control — go, step_over, step_into, set_breakpoint
• Raw — execute — run any debugger command, returns full text output
• Releasing — (--repo alone only proves the attestation came from some workflow in this repo; --signer-workflow pins it to the release workflow.)

Configuration and credentials

• Windows x64 (host bitness must match the target). - dbgeng.dll / dbghelp.dll — present in System32 on modern Windows 11 (verified with 10.0.26100). This is enough for live user-mode/kernel debugging and crash-dump analysis. - For crash-dump !analyze (and any other !-extension command), the engine needs the WinDbg winext\ extensions bundled next to the binary — System32's

Before you rely on it

• It runs with your machine's permissions. That is convenient and also the reason to think about what you point it at before you approve a tool call.
• MCP clients confirm each tool call by default. Leave that on until you have watched what the windbg mcp server does with a few real requests.

Choosing this one

This sits in the developer tooling group, where several servers overlap in what they claim to do but differ sharply once you actually set them up. Windbg's toolset — Group, Session, State and 3 more — is a fair guide to whether it matches your workflow. It is maintained by glslang; worth a glance at recent repository activity before you build anything load-bearing on it.

This entry was verified against Windbg's own documentation before publication; SyncDev keeps the directory reviewed rather than auto-generated.