Loading ToolBench
gdb-mcp has 7 tools with clear action-verb naming and reasonable descriptions. However, parameter descriptions are inconsistent, many lack granular constraints, and several parameters (like 'prompt' and 'force_prompt') are under-explained. Output schemas are partially documented in docstrings but not formalized in JSON Schema. Error handling is minimal; exceptions are raised but not guided toward recovery. The server uses in-memory session storage (_sessions dict) with no audit trail or permission gates. Tools are well-composed (each does one thing), but lack idempotency guarantees and partial-failure modes. Overall structure is solid for a domain-specific debugger tool, but falls short of production-grade LLM-tool standards.
Start gdb and attach to an existing process id.
Send multiple gdb commands in sequence.
Execute a raw gdb command within a session and return the output.
List active gdb sessions.
Report whether the given session still has a live gdb process.
Start a new gdb session for a binary and return the session id.
Shut down a gdb session and remove it from the registry.
Parameter descriptions lack actionable constraints. 'prompt' is documented as 'Optional custom gdb prompt string' but does not explain valid format, length limits, or how it interacts with 'force_prompt'. Similarly, 'timeout_seconds' lacks guidance on min/max or what happens if the timeout expires.
Output schemas not formally documented in JSON Schema format. Tool return types are inferred from docstring examples (e.g., '# :returns: Session metadata') and from code (dict with 'session_id', 'banner', 'session'). LLMs cannot reliably parse docstring-based schemas, a formal schema definition is required.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
Error handling lacks recovery guidance. When GdbNotStarted is raised (invalid session_id), the exception message is informative ('No gdb session with id X exists') but the tool does not suggest next steps (e.g., 'Call list_sessions() to see available sessions'). Errors should guide the LLM toward recovery.
No idempotency guarantees. start_binary and attach_to_pid create new sessions on every call. If an LLM retries due to a transient error, duplicate sessions accumulate. Idempotency is critical for agent robustness.
No permission gates or audit trail. Tools operate on in-memory _sessions dict with no access control or logging of who called what. A production MCP server must track agent identity, authorization, and action history.
list_sessions description is bare ('List active gdb sessions.') and does not explain the structure of returned session metadata, what fields are included, or when to call this tool. A discovery tool needs context for LLM selection.
No timeout or rate-limiting on gdb_command execution. An LLM could issue a long-running gdb command (e.g., 'disassemble' on a large binary) that blocks the MCP server indefinitely. Explicit timeout handling is present (timeout_seconds parameter) but error response on timeout is not documented.
batch_commands lacks partial-failure handling. If one command in a batch fails, the current code appends the output and continues, but does not indicate success/failure per command. The LLM cannot distinguish between 'command succeeded with output X' and 'command failed with error X'.
Missing confirmation step for irreversible operations. stop_session terminates a gdb process and removes it from the registry with no confirmation or dry-run option. An LLM could accidentally kill an important debugging session.
Parameters 'load_init' and 'force_prompt' have unclear semantics. What does 'force_prompt' do when 'load_init' is false? How do these settings affect gdb behavior? A user must read gdb_session.py to understand the interaction.