Loading ToolBench
MCP server that provides debugging capabilities using the Delve debugger for Go programs
This server presents a concerning quality profile. While tool names follow verb_noun conventions (start_debug, set_breakpoint, continue), the definitions lack critical depth. Tool descriptions average ~45 characters (well below the 194-char baseline for A+ tools), parameter descriptions are minimal or absent in several tools, output schemas are not documented in the provided code, and error handling recovery guidance is nowhere evident. The schema definitions shown are basic JSON objects without min/max constraints, format specifications, or enum restrictions. Most critically, we cannot verify the actual output schema structure from the provided source snippets, only input schemas are visible. This is a C-tier implementation that would require substantial refinement before production use.
Continue execution of a debug session
Evaluate an expression in the context of the current debug session
List all active debug sessions
Set a breakpoint at a specific line in a file
Start a debug session for a Go program
Start a remote debug session connected to a running Delve debugger
Terminate a debug session
Tool descriptions are severely under-specified (avg 45 chars vs 194-char baseline). 'Start a debug session for a Go program' and 'Terminate a debug session' lack context on WHEN to call them, what they return, or how they differ from related tools. LLMs cannot disambiguate purpose.
Output schemas are completely undocumented. The provided code shows only input schemas. We cannot verify what fields start_debug returns (session_id? metadata? status?), forcing LLMs to guess and breaking tool composition. Next tools that depend on start_debug output (e.g., set_breakpoint consuming session_id) have no documented contract.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameters lack descriptions in several tools. 'mode' in start_debug says 'Debug mode: exec or debug' but does not explain the runtime difference or when to choose each. 'args' is an array with no guidance on format (shell-escaped? JSON? space-delimited?). Ambiguous param docs force LLM guessing.
No enum constraints on mode parameter. 'mode' accepts free-form strings ('exec', 'debug', or hallucinated values?). Should use enum: ['exec', 'debug'] to prevent invalid inputs and let LLMs pick from known options.
Error handling recovery is completely absent. If start_debug fails, there is no guidance on what went wrong or what to try next ('Check if the binary exists', 'Try a different program path', 'Ensure go is installed'). LLMs receive only a failure signal with no recovery path.
Composition chain is broken. set_breakpoint requires 'session_id', we cannot verify that start_debug returns a session_id or that list_debug_sessions documents how to extract it. Missing output schema documentation breaks the assumption that tools chain together.
Tool 'continue' is ambiguous. Does it resume execution to the next breakpoint? Skip one statement? Run until a condition? The description 'Continue execution of a debug session' is generic (20 chars, below 34-char p10 threshold). Needs context on semantics and expected return.
No pagination or result limits documented. list_debug_sessions and evaluate (which may return large expressions) lack limit/offset parameters and result cap guidance. Returning thousands of debug sessions or expression outputs would blow the context window.
No idempotence guarantees. If an LLM retries set_breakpoint with the same parameters and the breakpoint already exists, does it fail silently, return success, or error? Non-idempotent behavior on retries risks duplicate breakpoints or failed resumption.
No validation constraints on numeric inputs. 'line' in set_breakpoint is an integer with no min/max. Can an LLM pass line=0? line=999999? No guidance on valid ranges forces the tool to handle invalid inputs or silently ignore out-of-range values.