Loading ToolBench
MCP server for kernel debugging, VM management, guest operations, and user-mode debugging via WinDbg, VMware, Frida, and dbgsrv
WinDbg MCP has 23 well-named tools with consistent verb_noun patterns (kd_*, guest_*, vm_*, umd_*). Descriptions are detailed and context-aware, averaging ~180 chars and explaining prerequisites, state requirements, and examples. However, input schemas are NOT visible in the provided source code, only parameter names and descriptions appear in method signatures. Without explicit JSON Schema definitions, schema quality cannot be verified. Error handling is present (try-catch blocks, precondition checks) but lacks structured error classification or recovery guidance. Tool composition is strong: each tool has a single responsibility, and output chaining is supported (e.g., guest_list_processes → guest_kill_process). Security is reasonable (no secrets in params, precondition validation), but no explicit permission gates or audit logging visible.
Returns the complete state of the system: VM power, VMware Tools, kernel debugger, guest operations availability, and user-mode debug sessions. ALWAYS allowed — call this whenever you're unsure about the current state.
Kill a process inside the guest VM by PID. The VM must be running (target NOT frozen). Use guest_list_processes first to find the PID.
List all running processes inside the guest VM. The VM must be running (target NOT frozen). Returns process names and PIDs.
Execute a command inside the guest VM and capture stdout/stderr. The VM must be running (target NOT frozen at a breakpoint). If the kernel debugger has frozen the VM, call kd_continue first. Examples: 'ipconfig /all', 'sc query MyDriver', 'dir C:\Windows\System32'. The command runs via cmd.exe /c, so pipe/redirect syntax works.
Copy a file from the guest VM to the host machine. The VM must be running (target NOT frozen). Use this to retrieve crash dumps, logs, or output files from the VM.
Input schemas not visible in source code. Only parameter names and descriptions appear in method signatures; no explicit JSON Schema definitions provided. Cannot verify schema completeness, type constraints, or enum declarations.
Error handling lacks structured classification and recovery guidance. Catch blocks return generic error messages (e.g., 'guest_transfer_to_vm failed: {ex.GetType().Name}: {ex.Message}') without actionable next steps or categorization (retryable vs. fatal).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | <=2025-11-25 | v2 |
Copy a file from the host machine to the guest VM. The VM must be running (target NOT frozen). Use this to deploy drivers, tools, or test binaries to the VM.
Break into a running target (equivalent to Ctrl+Break in WinDbg). Target must be running. After breaking, use kd_execute to inspect state.
Connect to the kernel debug target via KDNET or serial. The VM must be running with debug boot enabled. Target will break on connect (initial breakpoint). Optionally provide a raw connection string (e.g. 'net:port=50000,key=...' or 'com:pipe,port=\\.\pipe\com_1,resets=0,reconnect'); if omitted, connects using the defaults from appsettings.json.
Resume target execution (go). Returns immediately — the target starts running. Use kd_wait_for_event to check for breakpoint hits, or kd_break to halt again. Guest operations (vm_execute, vm_send_file) require the target to be running.
Disconnect from the kernel debug target. Resumes the target before disconnecting so the VM keeps running.
Execute any WinDbg command and return output. Target must be halted (at breakpoint). Examples: 'k' (stack), 'r' (registers), 'lm' (modules), '!process 0 0', '!analyze -v', 'db addr' (memory), 'u addr' (disassemble), 'bp symbol' (set breakpoint). Execution-control commands (g, t, p, gu, wt) are BLOCKED — use kd_continue/kd_step instead.
Step one instruction. Mode 'over' steps over calls, 'into' steps into calls. Target must be at a breakpoint (broken). Returns the new instruction pointer and disassembly.
Wait for a debug event (breakpoint hit, exception, etc.) with a timeout. Use this after kd_continue + set_breakpoint to wait for the breakpoint to be hit. ALWAYS returns within timeout — never hangs. If no event, target keeps running.
Perform Frida operations on an attached process. Actions: 'inject' (run JS script), 'eval' (one-liner JS), 'list' (list guest processes via frida-ps), 'detach', 'inject_bg' (start persistent background hook session), 'collect_bg' (read output from background session), 'stop_bg' (stop background session).
Attach Frida to a process in the guest VM for dynamic instrumentation. Requires: frida-tools installed on host (pip install frida-tools), frida-server.exe running in the guest VM. After attaching, use umd_frida to inject scripts, hook functions, etc.
Get Frida best practices, API reference, and usage patterns for the MCP Frida tools. Call this BEFORE using Frida if you are unfamiliar with the workflow.
Pause the VM. EVERYTHING freezes: kernel debugger, guest, network. This is different from kd_break! Use vm_resume to unpause.
Resume a paused VM. The VM must be in the Paused state (via vm_pause).
Capture a screenshot of the VM display. Useful for checking guest OS state (boot screen, BSOD, login screen, etc).
Switch the active VM target at runtime. All VM, guest, and snapshot operations will target the new VM after this call. If the kernel debugger is connected, it is cleanly disconnected first. Note: kd_connect uses its own connection string — this only affects guest/VM operations.
Restore a named snapshot. Destroys all debug sessions (Frida, dbgsrv). If the kernel debugger was connected, it is cleanly disconnected before restore and automatically reconnected afterwards — no manual kd_connect needed.
Start the VM. The VM must be powered off. After starting, wait for VMware Tools to report 'running' before using guest operations.
Stop the VM. Use hard=true for immediate power off, false for graceful shutdown.
Output schemas not documented. Tool descriptions do not specify what fields are returned or their types. LLMs cannot plan downstream tool calls or extract chaining IDs (e.g., what does guest_list_processes return? PID format? Process name format?).
No explicit permission gates or audit logging visible. Destructive tools (vm_stop, guest_kill_process, vm_snapshot_restore) lack permission checks or audit trails. No evidence of scope declarations (e.g., 'requires: write:vm, read:guest').
Mutually exclusive parameters not documented. umd_frida_attach accepts both processName and pid but description does not state they are mutually exclusive. LLMs may pass both, causing ambiguous behavior.