MCP server for debugging programs using GDB (GNU Debugger) with support for breakpoints, stepping, stack inspection, and variable monitoring
14 tools with complete schemas and descriptions, but significant quality gaps. All tools have input schemas with typed parameters and descriptions present. However, descriptions are often generic (10-50 chars) and lack actionable context for LLM selection. Tool names follow verb_noun convention well (start_debugging_session, set_breakpoint, get_stack_trace). No enum constraints on string parameters. Output schemas documented via Pydantic models but not exposed in tool definitions. Error handling present but minimal, no recovery guidance or categorization. Session-based architecture requires LLM to track session_id across calls, increasing cognitive load. No tool annotations (readOnlyHint/destructiveHint) despite clear read/write distinction in risk column.
Close a GDB debugging session
Continue program execution until the next breakpoint or program end
Delete a breakpoint by its number
Evaluate an expression in the current context
Get the current stack trace
Get the value of a variable or expression
List all breakpoints in the current debugging session
Descriptions lack actionable context. Most are 40-60 chars and do not explain WHEN to use the tool or what distinguishes it from similar tools. E.g., 'Execute the next line of code, stepping over function calls' does not explain when step_over is preferred over step_into.
No enum constraints on string parameters. 'location' in set_breakpoint accepts free-form strings (file:line, function, *address) but lacks enum or pattern validation. LLMs may hallucinate invalid formats.
Tool annotations missing. Risk column shows WRITE, READ_ONLY, REVERSIBLE but no destructiveHint/readOnlyHint/idempotentHint in schema. LLMs cannot infer safety properties without explicit annotations.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | <=2025-11-25 | v2 |
Run the program in the debugger until completion or a breakpoint
Set a breakpoint at a specific location in the code
Set the value of a variable
Start a new GDB debugging session for a binary
Execute the next line of code, stepping into function calls
Execute until the current function returns
Execute the next line of code, stepping over function calls
Session-based architecture requires LLM to track session_id across calls. No tool to list active sessions or auto-discover session_id. LLM must remember session_id from start_debugging_session output or fail subsequent calls.
Error handling minimal. Code shows try/except blocks that log and re-raise, but no categorization (retryable vs fatal) or recovery guidance. E.g., 'Invalid session ID' error does not suggest calling start_debugging_session.