Loading ToolBench
A GDB/MI protocol server based on the MCP protocol, providing remote application debugging capabilities
Server has 14 well-named tools with consistent verb_noun patterns (create_session, get_session, set_breakpoint, etc.). All tools have descriptions and input schemas are visible in the macro definitions. However, descriptions are terse (10-50 chars for most tools), parameter descriptions lack detail about constraints/formats, and output schemas are not documented. Error handling is minimal, tools return generic Result types without actionable recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Parameter validation rules and dependencies are undocumented.
Close a GDB debugging session
Create a new GDB debugging session with optional parameters, returns a session ID (UUID) if successful
Delete one or more breakpoints in the code
Get all GDB debugging sessions
Get all breakpoints in the current GDB session
Get local variables in the current stack frame
Get register names in the current GDB session
Parameter descriptions lack constraint details. E.g., 'session_id' has no format hint (UUID?), 'line' has no range (1-999999?), 'address' in read_memory lacks format (hex, decimal, expression syntax). LLMs cannot infer valid input ranges.
No output schemas documented. Tools return JSON via tool_text_content!() macro, but LLMs cannot see the structure of returned objects (e.g., what fields does a breakpoint object contain? What is the format of stack frames?). Agents must guess or parse unstructured text.
Tool descriptions are too brief (10-50 chars). Most lack context on WHEN to use the tool, WHAT it returns, or DEPENDENCIES. E.g., 'Get a GDB debugging session by ID' does not explain what a session contains or when to call it vs get_all_sessions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | <=2025-11-25 | v2 |
Get registers in the current GDB session
Get a GDB debugging session by ID
Get stack frames in the current GDB session
Read the memory in the current GDB session. This command attempts to read all accessible memory regions in the specified range. First, all regions marked as unreadable in the memory map (if one is defined) will be skipped. See Memory Region Attributes. Second, GDB will attempt to read the remaining regions. For each one, if reading full region results in an errors, GDB will try to read a subset of the region. In general, every single memory unit in the region may be readable or not, and the only way to read every readable unit is to try a read at every address, which is not practical. Therefore, GDB will attempt to read all accessible memory units at either beginning or the end of the region, using a binary division scheme. This heuristic works well for reading across a memory map boundary. Note that if a region has a readable range that is neither at the beginning or the end, GDB will not read it. The command will return a JSON object with the following fields: begin: The start address of the memory block, as hexadecimal literal. end: The end address of the memory block, as hexadecimal literal. offset: The offset of the memory block, as hexadecimal literal, relative to the start address passed to -data-read-memory-bytes. contents: The contents of the memory block, in hex bytes.
Set a breakpoint in the code
Start debugging in a session
Stop debugging in a session
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Risk field is present in metadata but not exposed to LLM. Tools like delete_breakpoint and close_session should be marked destructive; read tools should be marked read-only. Agents cannot reason about side effects.
Error handling returns generic Result<ToolResponseContent> with no recovery guidance. If a session_id is invalid or a breakpoint fails to set, the LLM receives a raw error with no hint on what to try next (e.g., 'Session not found. Call get_all_sessions() to list valid IDs.').