Loading ToolBench
MCP server providing debugging capabilities for x64dbg, a Windows debugger. Exposes tools to execute debugger commands, read/write memory, manage registers, set breakpoints, and retrieve debugging information via HTTP bridge.
This server exposes 8 debugging tools with mixed definition quality. Naming follows verb_noun conventions (ExecCommand, RegisterGet, MemoryRead) which is good. However, descriptions vary significantly in quality and actionability. Several critical issues: (1) descriptions lack context for WHEN to use each tool vs. alternatives, (2) parameter descriptions are minimal and sometimes example-dependent, (3) output schemas are documented in prose but not as formal JSON Schema structures, (4) error handling is not visible in definitions, no guidance on retry-ability or recovery paths, (5) no validation constraints on inputs (e.g., hex format for addresses is stated but not enforced), (6) the ExecCommand tool combines multiple concerns (arbitrary command execution, pagination, reference view parsing) which violates single-responsibility, (7) parameter types show string/integer but lack enum constraints where applicable (e.g., register names). The server operates a low-level debugger interface, so some complexity is inherent, but the definitions do not guide LLM usage effectively.
Execute a command in x64dbg and return its output Ensure that if if the command has arguments, you comma separate the values, but not the command itself I.E. findallmem findallmem 0x140001000,CC,20480 Parameters for commands that use the Reference View: cmd: Command to execute offset: Pagination offset for reference view results (default: 0) limit: Maximum number of reference view rows to return (default: 100, max: 5000) Returns: Dictionary with: - success: Whether the command executed successfully - refView: References tab data populated by the command (if any), with: - rowCount: Total number of rows in the references view - rows: List of rows (paginated), where each row is a list of cell strings (typically [address, disassembly] or [address, disassembly, string_address, string])
Check if debugger is active (running) Returns: True if running, False otherwise
Check if x64dbg is debugging a process Returns: True if debugging, False otherwise
Check if memory address is valid Parameters: addr: Memory address (in hex format, e.g. "0x1000") Returns: True if valid, False otherwise
Read memory using enhanced Script API Parameters: addr: Memory address (in hex format, e.g. "0x1000") size: Number of bytes to read Returns: Hexadecimal string representing the memory contents
ExecCommand violates single-responsibility principle: accepts arbitrary commands, handles pagination, and parses reference view output. This combines multiple concerns and makes it hard for LLMs to predict outcomes.
Parameter type mismatches: MemoryRead 'size' is typed as string but represents a byte count (should be integer). RegisterGet/RegisterSet/MemoryRead/MemoryWrite all accept register/address/data as strings without format validation or enum constraints. LLMs cannot validate input format.
Descriptions use examples (e.g., 'eax', 'rax', 'rip') instead of enum constraints. Pattern:tool-description forbids example values in text; they should be formal constraints. LLMs often reuse examples literally.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
Write memory using enhanced Script API Parameters: addr: Memory address (in hex format, e.g. "0x1000") data: Hexadecimal string representing the data to write Returns: Status message
Get register value using Script API Parameters: register: Register name (e.g. "eax", "rax", "rip") Returns: Register value in hex format
Set register value using Script API Parameters: register: Register name (e.g. "eax", "rax", "rip") value: Value to set (in hex format, e.g. "0x1000") Returns: Status message
No error handling documented for any tool. Pattern:recovery-guide requires error responses tell LLMs what to do: is this retryable? User-fixable? Fatal? Definitions provide no guidance. E.g., ExecCommand could fail (invalid command, permission denied) but no recovery path stated.
Destructive operations (MemoryWrite, RegisterSet) do not warn of side effects or irreversibility. Pattern:command-tool requires descriptions state if the tool modifies state. No confirmation or dry-run mechanism documented.
Output schemas documented in prose (e.g., 'Dictionary with: success, refView, rowCount, rows') but not as formal JSON Schema. Pattern:tool requires documented return types. LLMs cannot parse prose schemas reliably.
Hex format input/output not specified: should 0x prefix be required? Case (0xFF vs 0xff)? Byte order? Without formal constraints, LLMs guess and fail.
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint). Protocol spec 2026-07-28 rewards tool annotations for guiding agent planning.