Loading ToolBench
Standalone Language Server Protocol tools exposed as a stdio MCP server.
LSP Tools MCP has well-structured tool definitions with complete input schemas and consistent descriptions. All 11 tools have proper JSON Schema with typed parameters and descriptions. However, descriptions are brief (avg ~60 chars) and lack actionable context for LLM selection. Tool names follow verb_noun convention (lsp.status, lsp.diagnostics) but the 'lsp.' prefix is redundant given the server's single domain. Error handling is present but generic. Output schemas are not documented in the tool definitions themselves. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Parameter descriptions are adequate but lack format constraints and dependency hints.
Get code actions for a range using LSP
Get completions at a given position using LSP
Go to definition of a symbol at a given position using LSP
Get diagnostics for a file or directory using LSP
Get all symbols in a document using LSP
Get hover information for a symbol at a given position using LSP
Prepare to rename a symbol at a given position using LSP
Find all references to a symbol at a given position using LSP
Tool descriptions lack actionable context for LLM selection. Descriptions like 'Get diagnostics for a file or directory using LSP' (60 chars) do not explain WHEN to use this tool vs alternatives, what prerequisites exist, or what the output structure contains. Baseline for A-grade tools is 50-200 chars with explicit WHAT/WHEN/WHY guidance.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications in metadata. lsp.rename is marked WRITE but has no destructiveHint annotation. Modern MCP spec (2026-07-28) expects these annotations for agent safety.
Output schemas are not documented in tool definitions. ToolExecutionResult interface exists in code but is not exposed to the MCP protocol layer. LLMs cannot see what fields to expect (e.g., lsp.diagnostics returns LspDiagnosticsDetails with 'truncated', 'totalDiagnostics', 'errorKind' fields) without reading implementation code.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Rename a symbol at a given position using LSP
Get the status of configured and active LSP servers
Search for symbols in the workspace using LSP
Parameter descriptions lack format constraints and dependency hints. E.g., 'line' and 'character' parameters lack 0-indexing clarification in descriptions (only in tool description). 'severity' enum is documented but other enums lack examples of when each value is useful.
Tool names use 'lsp.' prefix (e.g., 'lsp.diagnostics', 'lsp.rename') which is redundant given the server's single domain. Shorter names like 'diagnostics', 'rename', 'definition' would reduce token overhead and improve clarity.