Loading ToolBench
The server exposes 8 well-named LSP tools with mostly complete schemas and descriptions. Naming follows verb-noun convention (goto_definition, find_references, rename_symbol, etc.) which is excellent. Descriptions are present and range from adequate to good (50-150 chars typical). Schemas are properly typed with required fields and parameter descriptions. However, there are gaps in output schema documentation (no visible return types), limited error handling guidance, and missing actionable error messages. Parameter descriptions are present but sparse, most lack detail about constraints, formats, or usage context. The tools themselves are well-scoped and composed logically, but the overall quality is dragged down by incomplete error handling and sparse output documentation.
Apply workspace edits (typically from rename, refactoring operations) to files on disk with automatic backup creation
Find all references to a symbol at a specific location in a file
Get diagnostics (errors, warnings) for a file from the LSP server
Get hover information (type hints, documentation) for a symbol at a specific location
Get all symbols defined in a file with their locations and types
Jump to the definition of a symbol at a specific location in a file
Rename a symbol at a specific location. Returns edits that need to be applied but does not apply them automatically.
Manually restart LSP servers. Can restart servers for specific file extensions or all running servers.
Output schemas are not documented. No visible return type definitions for any tool. LLMs cannot infer what fields to extract or chain downstream tools without knowing the response structure.
Error handling lacks recovery guidance. Tools do not provide actionable error messages telling the LLM what to do if a call fails (retry, try alternative tool, ask user, etc.). For example, restart_server provides no guidance on handling timeout or permission failures.
Parameter descriptions are minimal. Most parameters lack detail about constraints, expected formats, or valid ranges. For example, 'line' and 'character' parameters lack specification of what happens with out-of-bounds values, whether they are inclusive/exclusive, or line ending handling.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 20 | - | v1 |
apply_edits tool lacks a dry-run or confirmation step despite being reversible but destructive. Agents should be able to preview changes before applying them, especially since createBackups defaults to true but agents cannot know if backups succeeded.
Sparse output documentation means tools cannot be composed effectively. If rename_symbol returns file URIs as strings vs objects, apply_edits may not accept them. If get_symbols returns a flat list vs nested structure, agents cannot plan downstream operations.
The file parameter in navigation tools accepts an absolute path but does not document how symlinks, relative paths, or non-existent files are handled. This invites errors and prevents LLMs from validating paths before calling.