Loading ToolBench
Visual Studio extension providing MCP tools for Claude integration with IDE capabilities (build, file operations, project structure, debugging)
Four build-related tools with clear verb-noun naming (build_project, build_solution, build_cancel, build_clean). All have descriptions (194 - 392 chars, within baseline). Input schemas present with enums for severity parameter. However, descriptions are verbose and procedural rather than LLM-optimized; they read like IDE documentation rather than agent guidance. Parameter descriptions are adequate but lack constraint details (e.g., no guidance on valid project names). Output schemas are not documented, LLMs cannot infer what fields to expect from build results. Error handling is implicit (ok/failedProjects fields mentioned in descriptions but not formally specified). No pagination, no batch operations. Composition is reasonable (separate tools for project vs solution, cancel, clean) but lacks idempotency guarantees and recovery guidance.
Stop the build currently running in the IDE and wait for it to actually stop. Reports ok=true once the IDE is free again — including when nothing was running, since that is the state you asked for; ok=false means the build is still going and the message says why. Use it when build_solution or build_clean reported a timeout (the build was left running), or when a build started outside the chat is in the way. A cancelled build leaves partial outputs, so run build_clean before trusting the next one.
Clean the entire solution: delete the build outputs (bin/obj) of every project. Blocks until the clean ends. Use it when a build result looks stale, then call build_solution to rebuild — cleaning on its own produces no diagnostics.
Build a single project (by name) in the active configuration and return whether it succeeded plus what the Error List holds (file, line, description, severity). Blocks until done. Reports errors only unless severity says otherwise; the message says how many items were left out, and 'configuration' says which one it built — solution_set_configuration changes it. ok/failedProjects/message are the outcome; 'errors' is the Error List, which the IDE updates a moment later and which can hold entries from a debug session as well as from the build — ide_read_output('Build') has the compiler's own log when the two disagree. The name is a project name, not a path — ide_get_project_structure lists them. build_solution builds everything instead.
Build the entire solution and return whether it succeeded plus what the Error List holds (file, line, description, severity). Blocks until the build ends. Reports errors only unless severity says otherwise; the message says how many items were left out. Prefer this to a dotnet build in the shell: it goes through the open IDE, so there is no path to resolve and no clash with a debug session. Builds whichever configuration the IDE has active and reports it back as 'configuration' — solution_set_configuration changes it. ok/failedProjects/message are the outcome; 'errors' is the Error List, which the IDE updates a moment later and which can hold entries from a debug session as well as from the build. ide_read_output('Build') has the compiler's own log when the two disagree. build_project builds one project instead.
Output schemas not documented. Descriptions mention 'ok/failedProjects/message/errors' fields but no formal schema is visible. LLMs cannot plan downstream actions or extract structured data reliably.
Descriptions are procedural and verbose (300+ chars), reading like IDE help text rather than agent guidance. They explain implementation details (IDE updates Error List a moment later, debug session entries) that distract from the core action. Should be 50 - 150 chars: 'Build the entire solution and return success status plus compiler errors.'
No error recovery guidance. Descriptions mention timeouts and partial outputs but do not tell the LLM what to do: 'If build times out, call build_cancel() then retry.' Agents need actionable next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Parameter 'projectName' lacks constraint documentation. No guidance on valid names, case sensitivity, or how to discover available projects. Description says 'Project name (or file name without extension)' but does not explain the lookup mechanism.
No idempotency guarantees. Descriptions do not state whether repeated calls with the same input produce the same result or trigger side effects. Agents retry on ambiguous failures, non-idempotent tools risk duplicate builds.