Loading ToolBench
MCP server exposing x64dbg debugger functionality to LLMs. Provides tools for debugging, memory inspection, disassembly, breakpoint management, and process control via a local HTTP bridge to the x64dbg_mcp plugin.
Strong tool naming (verb_noun pattern, clear intent) and comprehensive descriptions (avg 180 chars, well above 10-char minimum). All 24 tools have explicit descriptions and input schemas with typed parameters. However, output schemas are undocumented, LLMs cannot predict response structure for downstream chaining. Parameter descriptions are present but lack format constraints (e.g., hex string validation, address expression syntax). Error handling is minimal; tools return raw JSON without recovery guidance. Missing idempotency hints on write operations and confirmation patterns for destructive tools (dbg_stop, dbg_write_memory).
Attach the debugger to a running process by PID. Guarded: if already attached to that same PID it is a no-op; if attached to a different target it refuses (detach/stop first) — re-attaching to the active debuggee would kill it.
Execute a raw x64dbg command synchronously (e.g. 'init C:\\path\\app.exe', 'run', 'bp kernel32.CreateFileW', 'StepOver'). Returns whether the command was accepted. Use this for anything without a dedicated tool.
Delete the software breakpoint at the given address/expression.
Detach from the current debuggee, leaving it running.
Disassemble 'count' instructions starting at 'address'. Returns each instruction's address, size, text, and branch target when applicable.
Evaluate an x64dbg expression and return its numeric value (decimal + hex). Accepts registers, module exports, arithmetic, etc. (e.g. 'cip', 'kernel32.CreateFileW', 'rax+8', '[rsp]').
Output schemas undocumented. Tools return JSON but LLMs cannot predict field names, types, or structure. Breaks downstream tool chaining and forces agents to guess response format.
Destructive operations (dbg_stop, dbg_write_memory) lack confirmation or dry-run patterns. Agents can irreversibly terminate debuggee or corrupt memory without safeguards.
Parameter descriptions lack format constraints. 'hexBytes' accepts any string; 'address' accepts any expression. No validation guidance for LLMs on valid formats (hex syntax, address expression grammar).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | <=2025-11-25 | v2 |
List all breakpoints (software, hardware, memory, dll, exception) with their address, state, type, and hit count.
Load and start debugging an executable. Optionally pass command-line arguments.
Get the debuggee's memory map: base, size, protection, state, type, and info (module/section) of each region.
Pause the running debuggee.
List running processes on the system (pid, exe, window title, args) — use to pick a target for dbg_attach. Works even when not debugging.
Read bytes from the debuggee's memory. 'address' may be a number or any x64dbg expression. Returns the bytes as a hex string.
Read the general-purpose CPU registers of the current thread (architecture-neutral names: cax, cbx, ... cip; r8-r15 on x64; eflags).
Restart the current debuggee from the beginning.
Resume execution of the debuggee (equivalent to F9 / the 'run' command).
Set a breakpoint at an address/expression. type: 'software' (default), 'hardware', or 'memory'.
Full debugger status/info: debugging? running vs paused; the target (name/path/base/entry), pid, peb, command line, current thread id and thread count, and cip/module/label/instruction. IMPORTANT: when running=true the CPU state (registers/cip/stack) is a stale snapshot — 'stateLive' is false and you must pause for coherent state.
Step into one instruction (single-step). Use dbg_step_over to step over calls.
Run until the current function returns (step out).
Step over one instruction, executing calls to completion.
Stop debugging / terminate the current debuggee.
Switch the active thread by thread id.
List the debuggee's threads (number, id, cip, entry, suspend count, name) and which is current.
Write bytes into the debuggee's memory. 'address' may be a number or expression. 'hexBytes' is a hex string like 'C3' or '4889e5'.
No error recovery guidance. Tools return raw success/failure without actionable next steps. E.g., 'command failed' does not tell LLM whether to retry, adjust syntax, or try a different tool.
Missing idempotency declarations. Write operations (dbg_set_breakpoint, dbg_attach) do not state whether repeated calls with same input are safe. Agents may retry on ambiguous failures, causing duplicate side effects.