Loading ToolBench
MCP server for VS Code debugging with tools for breakpoints, debug control, and variable inspection
Debugssy demonstrates solid tool definition quality with consistent naming conventions, present descriptions, and complete input schemas. However, there are notable gaps in output documentation, missing parameter descriptions for some fields, and limited error handling guidance. The tool set is well-composed for a debugging domain, but several tools lack the detail needed for optimal LLM routing and error recovery.
Clear all console output from the debug session
Continue execution from the current pause point (full automation mode only)
Evaluate a JavaScript/TypeScript expression in the current debug context with security validation and optional user approval for risky operations
Get the current call stack from the debug session
Get console output from the debug session, optionally filtered by category and limited by count or time
Get the current debug session state including execution status, location, and stopped information
Get list of threads in the current debug session
Output schemas not documented in visible code. No explicit return type definitions for tools (e.g., list_breakpoints, get_variables, get_debug_state). LLMs cannot plan downstream tool chains without knowing which fields to extract.
Generic execution control tools (continue, pause, restart) lack specific descriptions of what happens when called. 'Continue execution from the current pause point' is vague, does it resume all threads? What if no breakpoint is hit? When should an agent call this vs. step_over?
Error handling guidance missing. Tools do not describe what errors can occur or how to recover. For example, set_breakpoint could fail if the file doesn't exist, line is out of range, or syntax is invalid in the condition expression. Responses do not guide the LLM on recovery actions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 76 | <=2025-11-25 | v2 |
| 2026-03-09 | B | 71 | 2025-11-25+ | v1 |
Get variables in the current or specified stack frame, organized by scope
Inspect the state of a breakpoint including editor state, session state, adapter state, and execution history
List all currently set breakpoints
Pause execution in the current debug session (full automation mode only)
Remove all currently set breakpoints
Remove a breakpoint at a specific file location
Restart the current debug session (full automation mode only)
Set a breakpoint at a specific file location with optional condition, hit condition, or log message
Start a debug session with the specified configuration (full automation mode only)
Step into the next function call (full automation mode only, requires allowStepOperations setting)
Step out of the current function (full automation mode only, requires allowStepOperations setting)
Execute the next statement without stepping into function calls (full automation mode only, requires allowStepOperations setting)
Stop the current debug session (full automation mode only)
Toggle a breakpoint's enabled/disabled state at a specific location
Wait for execution to pause at a breakpoint with optional timeout
Automation level gating documented in code (assistedMode vs fullMode) but not reflected in tool descriptions. Tools like start_debugging, step_over, step_into note '(full automation mode only)' but lack guidance on what an LLM should do if the setting is disabled. Should it suggest enabling the setting or recommend an alternative?
Tool compositions require multi-step LLM reasoning. Setting a breakpoint and waiting for execution requires two calls (set_breakpoint, wait_for_breakpoint). Typically high-value operations should be wrapped into single tools to reduce latency and failure points.