Loading ToolBench
VS Code extension that provides an MCP server for AI assistants to interact with your development environment
The server provides 25 tools with complete input schemas and descriptions. However, there are significant gaps in error handling guidance, output schema documentation, and composition patterns. Naming is consistent (verb_noun format with prefixes like 'debug_', 'refactor_'), but descriptions vary in quality and length. Many tools lack actionable error recovery guidance. The 'format' parameter is omnipresent but its impact on output structure is not formally documented. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible in the source, despite tools having clear risk classifications (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE). Parameter descriptions are present but often generic. The tool set is well-composed with clear single responsibilities, but lacks cross-tool integration patterns and dependency hints.
Find what calls a function or what a function calls by using the function name. Perfect for understanding code flow and dependencies - faster than manually tracing through files
Remove all breakpoints from the workspace
Continue execution from the current breakpoint or paused state
Evaluate an expression in the current debug context (REPL/watch functionality). Test hypotheses instantly - execute any expression without modifying code
Get the call stack (stack trace) of the current debug session
Get debug session output (console, stdout, stderr logs)
Inspect variables and their values at the current debug position or in a specific stack frame
No tool annotations visible in source code. Tools are classified by risk (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE) but MCP-compliant readOnlyHint, destructiveHint, and idempotentHint attributes are absent. This prevents clients from auto-enforcing safety constraints.
Output schemas are not formally documented. While descriptions mention 'compact' vs 'detailed' format options, the actual structure of responses (what fields are returned, types, nesting) is not specified. LLMs cannot plan downstream tool calls without knowing response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
List all breakpoints in the workspace
List all available debug configurations from launch.json
Pause execution in the current debug session
Set a breakpoint at a specific line in a file
Start a debug session with a specific configuration
Get current debug session status and configuration information
Step into the next function call in the debugger
Step out of the current function in the debugger (continue until current function returns)
Step over the next line in the debugger (execute current line and stop at next line)
Stop the current debug session
Toggle a breakpoint at a specific line (add if not present, remove if present)
Jump to the definition of a symbol at a specific location
Get diagnostics (errors, warnings) for a file or the entire workspace
Get hover information at a specific location in a file (type hints, documentation, etc.)
Rename a symbol across the entire workspace. Safe refactoring that handles all references automatically
Find all references to a symbol in the workspace
Search for symbols (functions, classes, variables) in a specific file by name
Search for symbols (functions, classes, variables) across the entire workspace
Error handling lacks actionable recovery guidance. Tools do not document what errors can occur, how to categorize them (retryable vs user-fixable vs fatal), or what the LLM should do next. For example, 'breakpoint already set' errors are not documented.
No composition hints or dependency documentation. Tools do not explain the prerequisite relationships (e.g. 'Call debug_startSession before debug_setBreakpoint', 'debug_getCallStack requires an active debug session'). This forces LLMs to discover dependencies through trial and error.
Description lengths are inconsistent and often minimal (< 100 chars). For instance, 'Get current debug session status and configuration information' (54 chars) does not explain WHEN to use this tool instead of debug_listConfigurations, or what fields are in 'configuration information'. Descriptions should explain intent and differentiate similar tools.
Optional parameters lack clear default behavior. For example, 'symbolSearch' with no 'kind' returns 'all' types, but this is not stated in the parameter description. Similarly, debug_inspectVariables scope 'all' is the default but its behavior (what scopes are included) is not documented.
No pagination hint in workspaceSymbols. With a default limit of 50 and no total count or next_cursor in the response schema, LLMs cannot determine if results are truncated or how to fetch the next page. Large workspaces will silently lose results.
The 'format' parameter (compact vs detailed) appears on all 25 tools but its semantics are never defined. What fields does 'compact' omit? What does 'detailed' add? This forces LLMs to guess or requires the user to ask.
Parameter descriptions lack constraint information. For example, 'line' and 'character' are described as '0-indexed' but do not state valid ranges (0 to file length? 0 to 1000000?). 'levels' in debug_getCallStack lacks a minimum/maximum. Unbounded parameters invite invalid LLM inputs.
No idempotency guarantees documented. For instance, calling debug_setBreakpoint twice with the same params, is the second call a no-op or an error? Agents retry on ambiguous failures; non-idempotent tools risk side effects.