Loading ToolBench
MCP server that forwards a 32-bit x96dbg debugger session to MCP-aware clients, enabling debugger tooling access from editors like Cursor and VS Code without leaving the editor
X96Dbg MCP Server provides 21 debugger-oriented tools with reasonable naming conventions and basic descriptions. However, the implementation exhibits significant gaps in parameter documentation, output schema clarity, and error handling guidance. While tool names follow verb-first conventions (readMemory, writeMemory, listModules, getRegisters), many parameter descriptions are minimal or absent. Output schemas are not explicitly documented in the visible source code, responses are wrapped in a generic envelope with 'content' and 'structured' fields, but the actual return types for each tool are not clearly specified. Error handling is minimal: there is no guidance for recovery, no categorization of error types (retryable vs. fatal), and no actionable error messages. The code shows basic structure and covers a coherent domain (32-bit debugger introspection), but falls short of production-grade tool quality. Average tool score: 58/100.
Delete a breakpoint.
Disable a breakpoint.
Enable a breakpoint.
Disassemble up to 64 instructions from an address.
Inspect module export tables.
Inspect module import tables.
Inspect rights and guard bits for an address.
Many parameter descriptions are missing or minimal. Tools like getExports, getImports, getRegisters, getThreads lack detailed input documentation. LLMs cannot infer whether 'module' accepts base address hex format, module name string, or both.
Output schemas are not documented for any tool. The code wraps responses in a generic envelope with 'content' and 'structured' fields, but what fields does listModules return? What is the structure of getThreads output? LLMs need documented return types to plan downstream calls.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Snapshot general, debug, and flag registers.
Inspect debugger threads, priorities, wait reasons, and CIP.
Retrieve trace record data.
List all x96dbg breakpoints.
Enumerate loaded modules with base, size, entry, and sections.
Helper for memory-breakpoint diagnostics.
Query whether an address is a code page.
Binary pattern search with wildcard support.
Lightweight health check.
Dump bytes from the target address space (max 4 KB per call).
Helper for trace and memory-breakpoint diagnostics.
Set a breakpoint at an address.
Modify memory protections.
Patch bytes with optional temporary page-rights escalation.
No error handling guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. Example: if readMemory fails with 'address out of bounds', should the agent retry, ask the user, or abandon the plan?
Parameter 'address' is used in many tools (readMemory, writeMemory, getDisassembly, setBreakpoint, etc.) but its acceptable format is not clearly documented. The description says 'hex string or integer' but does not specify endianness, prefix format (0x vs bare hex), or bit width (32-bit only per the overview).
Ambiguous tool names: memBpSize, runTrace, getTraceRecord do not clearly convey their purpose. 'memBpSize' appears to be 'memory breakpoint size' but that is unclear. 'runTrace' vs 'getTraceRecord' suggests duplicate responsibility without clear distinction.
No pagination documented for list-style tools. listModules, listBreakpoints, and getImports/getExports may return large result sets, but there is no mention of limit/offset parameters or result counts. Without pagination, large results can exhaust the LLM context window.
The 'type' parameter in setBreakpoint (accepts 'normal, hardware, memory, dll, exception') is an enum but not declared as such in the schema. Free-form string input invites invalid values. The description should list allowed enum values and declare the parameter as type:string with enum constraint.
No documentation of prerequisites or dependencies. Many tools require the debuggee to be paused (mentioned in overview resource but not in tool descriptions). Tools should state 'Requires: debuggee paused' or 'Requires: breakpoint set' in descriptions so LLMs know when to call them.
No confirmation pattern for destructive operations. writeMemory, deleteBreakpoint, and setPageRights modify state but do not support dry-run or confirmation. Agents can accidentally corrupt memory or delete critical breakpoints without verification.