Loading ToolBench
MCP server that bridges Language Server Protocol (LSP) servers with the Model Context Protocol, exposing code intelligence and manipulation tools
The server registers 5 tools with explicit schemas and descriptions visible in tools.go. All tool names follow verb_noun convention and descriptions are present, ranging from 70-180 characters. However, several critical gaps reduce quality: (1) Parameter descriptions are minimal or absent for complex nested objects like the 'edits' array in edit_file; (2) Output schemas are completely undocumented, no guidance on what fields agents should expect from tool responses; (3) Error handling lacks actionable guidance; (4) No validation constraints documented (enums, ranges, formats) despite tools accepting free-form input; (5) Security considerations for the write-access edit_file tool are not addressed. The edit_file tool is particularly concerning: it accepts arbitrary line ranges and text with no documented validation, no dry-run capability, and no recovery guidance if edits corrupt a file.
Read the source code definition of a symbol (function, type, constant, etc.) from the codebase. Returns the complete implementation code where the symbol is defined.
Get diagnostic information for a specific file from the language server.
Apply multiple text edits to a file.
Get hover information (type, documentation) for a symbol at the specified position.
Find all usages and references of a symbol throughout the codebase. Returns a list of all files and locations where the symbol appears.
Output schemas completely undocumented. No guidance on what fields agents should expect from tool responses. LLMs cannot plan downstream calls or extract relevant data without knowing response structure.
edit_file tool is destructive (WRITE operation) but lacks error handling, validation constraints, and confirmation step. No guidance on how to recover if edits corrupt a file. No documented return schema (success/failure per edit?).
Parameter constraints are absent. edit_file accepts startLine/endLine as numbers with no documented bounds (could be negative, zero, or beyond file length). references/definition accept symbolName with no documented format. diagnostics contextLines is boolean but unclear semantics.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Error handling lacks actionable guidance. No documented error cases or recovery paths. E.g., what does definition return if symbolName not found? What does edit_file return on validation failure? Generic errors force LLM to guess next steps.
edit_file parameter descriptions lack critical detail. The 'edits' array contains objects with startLine/endLine/newText, but the description for nested object properties is minimal. Nested schema properties should explain: are line numbers 0-indexed or 1-indexed? (appears to be 1-indexed per description, but not enforced). What is newText behavior (replace lines entirely, or insert)?