MCP server for WinDbg / DbgEng debugging integration, supporting crash dump analysis, live process debugging, memory inspection, and execution control
23 tools with explicit schemas and descriptions, but significant quality gaps. Tool names are action-oriented (open_, attach, execute, etc.) following verb_noun convention. However, descriptions are inconsistent: some are 10-15 chars (e.g., 'Attach debugger to a running process' is adequate at 42 chars), but many lack context on WHEN to use them or what they return. Parameter descriptions exist but are minimal (e.g., 'Session ID' with no guidance on format or origin). Output schemas are not documented, LLMs cannot predict what fields to expect from tools like analyze, stack_trace, or read_memory. Error handling is absent from descriptions. No guidance on idempotency, retryability, or side effects. The write_memory tool (DESTRUCTIVE risk) lacks a confirmation pattern or dry-run option. Script-related tools (load_script, run_script, invoke_script, eval_script) have overlapping responsibilities and unclear composition. Session management is implicit (session_id parameter everywhere) but never explained, how do sessions persist? Are they per-process? Per-connection? This forces LLMs to guess.
Analyze crash dump or debug session
Attach debugger to a running process
Set a breakpoint at an address
Connect to a remote debugging session
Disassemble code at an address
Evaluate JavaScript code using the dx command
Execute a debugger command
Continue execution of the debugged process
Output schemas undocumented. Tools like analyze, stack_trace, read_memory, and registers lack documented return types. LLMs cannot predict field names or structure, forcing them to guess what data is available for downstream operations.
Session management implicit and unexplained. Every tool accepts session_id but descriptions never explain what a session is, how to obtain one, or whether sessions persist across connections. This forces LLMs to infer session semantics.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Invoke a function from a loaded JavaScript script
Load a JavaScript script for debugging
Open a crash dump file for analysis
Read memory from the debugged process
Get register values
Remove a breakpoint
Resolve symbol name to address or address to symbol
Run a JavaScript script
Search for a pattern in memory
Get stack trace for a thread
Step through code execution
Switch to a different thread
Get type information for a type in a module
Unload a JavaScript script
Write data to memory in the debugged process
Destructive tool (write_memory) lacks confirmation or dry-run pattern. No guidance on retryability, idempotency, or recovery. Agents could accidentally corrupt memory without safeguards.
Script tools (load_script, run_script, invoke_script, eval_script) have overlapping responsibilities and unclear composition. No guidance on when to use invoke_script vs eval_script, or how they interact with loaded scripts.
Parameter descriptions are minimal. Many parameters (e.g., 'Session ID', 'Thread ID', 'Address') lack format guidance, valid ranges, or examples. LLMs cannot validate inputs before calling.