Loading ToolBench
GDB MCP server provides 14 well-structured debugging tools with complete schemas and descriptions. Naming follows verb_noun convention consistently (gdb_start_session, gdb_execute_command, etc.). Most tools have detailed descriptions (100-400+ chars) explaining purpose, when to use, and prerequisites. All parameters have type definitions and descriptions. However, output schemas are NOT documented, responses are inferred from GDB output but not formally specified in tool definitions. Error handling guidance is minimal; tools do not explain recovery steps or categorize errors as retryable vs fatal. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite clear risk classifications (WRITE vs READ_ONLY). Some parameter descriptions could be more concise, gdb_start_session description exceeds 1024 chars. Overall above-average tool design with clear composition and chainability, but lacks production-grade error recovery and output schema documentation.
Call a function in the target process and return its result. Similar to using the 'call' command in GDB, but with better structured output. The function must be accessible in the current debugging context. Use this to invoke helper functions for debugging purposes. Example: gdb_call_function(session_id=1, function_call="printf(\"hello\\n\")")
Delete a breakpoint by its number. Breakpoint numbers are shown in 'info breakpoints' output.
Evaluate a C/C++ expression in the context of the current stack frame. Can be used to inspect variable values, call functions, or perform calculations. The expression must be valid for the current debugging context.
Execute a GDB command. Supports both CLI and MI commands. CLI commands (like 'info breakpoints', 'list', 'print x') are automatically handled and their output is formatted for readability. MI commands (starting with '-', like '-break-list', '-exec-run') return structured data. NOTE: For calling functions in the target process, prefer using the dedicated gdb_call_function tool instead of 'call' command, as it provides better structured output and can be separately permissioned. Common examples: 'info breakpoints', 'info threads', 'run', 'print variable', 'list main', 'disassemble func'. Requires session_id parameter (obtained from gdb_start_session).
Output schemas not documented. Tools return results but definitions do not specify return types, field names, or structure. LLMs cannot predict what fields will be available for downstream chaining or decision-making. See gdb_execute_command, gdb_get_status, gdb_get_threads, all lack documented return schemas.
No tool annotations. All tools lack readOnlyHint, destructiveHint, or idempotentHint despite explicit Risk classification in metadata (WRITE vs READ_ONLY). LLMs cannot infer whether a tool is safe to retry, safe to dry-run, or destructive without annotations. Affects all 14 tools.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 23 | - | v1 |
Get the call stack (backtrace) for a thread. Shows the sequence of function calls that led to the current location. Useful for understanding program flow and debugging crashes. Requires session_id parameter.
Get a list of all breakpoints in the current debugging session. Returns breakpoint numbers, locations, hit counts, and other information.
Get the current status of the GDB session. Requires session_id parameter (obtained from gdb_start_session).
Get information about all threads in the debugged process, including thread IDs, states, and the current thread. Requires session_id parameter (obtained from gdb_start_session).
Get local variables and arguments in a stack frame. Returns the names, types, and current values of variables visible in the specified frame.
Select a stack frame to inspect. Frame 0 is the innermost (current) frame. Subsequent commands like gdb_get_variables will operate on the selected frame.
Select a specific thread to make it the current thread. After selecting a thread, subsequent commands like gdb_get_backtrace will operate on that thread. Requires session_id and thread_id parameters.
Set a breakpoint at a specific location. Breakpoints pause program execution at the specified location, allowing inspection of program state. Locations can be function names, file:line numbers, or memory addresses. Supports conditional breakpoints and temporary breakpoints.
Start a new GDB debugging session. Can load an executable, core dump, or run custom initialization commands. Automatically detects and reports important warnings such as: missing debug symbols (not compiled with -g), file not found, or invalid executable. Check the 'warnings' field in the response for critical issues that may affect debugging. Available parameters: program (executable path), args (program arguments), core (core dump path - uses --core flag for proper symbol resolution), init_commands (GDB commands to run after loading), env (environment variables), gdb_path (GDB binary path), working_dir (directory to run program from). IMPORTANT for core dump debugging: Set 'sysroot' and 'solib-search-path' AFTER loading the core (either via 'core' parameter or 'core-file' init_command) for symbols to resolve correctly. Returns a session_id integer that must be passed to all other GDB tools.
Stop a debugging session and clean up resources. After stopping, the session_id can no longer be used.
No error handling guidance. Tools do not explain recovery steps, error categories, or next actions. A failed gdb_execute_command returns nothing actionable, the LLM cannot distinguish between 'invalid syntax (try again)' vs 'session crashed (restart)' vs 'permission denied (ask user)'. Affects all tools.
gdb_start_session description exceeds 1024 chars (approximately 1200+). While detailed, this violates the recommended upper bound for descriptions. Extract verbose explanation into separate parameter descriptions or examples documentation.
Minimal parameter descriptions on generic read tools. gdb_get_status, gdb_get_threads, gdb_stop_session have single-line descriptions ('Get the current status...', 'Get information about...') that lack context on WHEN to call them vs similar tools or what they return structurally. Baseline: A+ tools average 72 chars per param description; these average ~50 chars.
No pagination or result-limiting strategy documented. gdb_get_backtrace accepts max_frames (capped at 100), but other discovery tools (gdb_get_threads, gdb_get_breakpoints) have no limit parameters. If a process has 1000 threads, gdb_get_threads returns all, potentially exhausting LLM context. Missing limit/offset pattern.
No confirmation or dry-run for destructive operations. gdb_delete_breakpoint, gdb_call_function, and gdb_stop_session can have side effects but lack a dry-run mode or confirmation step. An LLM in a retry loop could accidentally delete all breakpoints or terminate a session without recovery.