Loading ToolBench
MCP server that provides code analysis tools for .NET projects by integrating with Language Server Protocol (LSP) servers
This C# LSP server exposes 9 code navigation and diagnostics tools with good naming conventions (verb-noun pattern) and solid descriptions. All tools are READ_ONLY and implement proper input schemas with typed parameters. However, there are significant gaps: (1) Output schemas are not documented, responses are TextContentBlock collections with no formal schema specification; (2) Parameter descriptions, while present, lack granularity around constraints (e.g., line/character must be 1-based, but no min/max bounds declared); (3) No error handling guidance, exceptions are thrown but recovery paths are not documented; (4) No pagination support despite tools returning potentially large result sets; (5) Four experimental tools (get_unhandled_notifications, get_unhandled_requests) lack justification and have minimal descriptions. Tools follow a consistent pattern with good discovery potential via names like 'go_to_definition', 'find_references', 'completion'. The completion tool's 186-char description is exemplary. However, missing output schema documentation and lack of error recovery guidance prevent a higher score.
Gets code completion suggestions at a specific position in a file. Returns a list of possible completions including variables, methods, classes, and other language constructs available at the cursor position. Useful for exploring what's available in scope or after an object/class reference.
Finds all references of a symbol starting from its location in the C# codebase. Returns both the symbol declaration and all usages across the solution.
Gets diagnostics for a specified file sorted by severity (Error → Warning → Information → Hint) and by line number
Parses the symbols from a specified code file. Useful for understanding the structure and contents of large files without requiring position coordinates.
Retrieves unhandled LSP notifications caught by the catch-all handler
Retrieves unhandled LSP server-to-client requests caught by the catch-all handler
Output schemas not documented. Tools return TextContentBlock enumerables but no formal schema (fields, types, structure) is specified. LLMs cannot plan downstream operations or extract typed data without schema documentation.
No error handling guidance. Exceptions are thrown (InvalidOperationException in completion tool) but no recovery paths are documented. LLMs receive raw error messages without actionable next steps.
Parameter constraints underspecified. Line and character parameters documented as '1-based' in descriptions but no numeric min/max bounds in schema (e.g., {"type": "uint", "minimum": 1}). LLMs cannot validate or constrain inputs precisely.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Unified navigation tool that performs all go-to operations (definition, type definition, implementation) for a symbol and returns separate text blocks for each type of navigation result found
Navigates to the definition of a symbol starting from its location. Returns the source location where the symbol is defined
Navigates to the implementation of a symbol starting from its location. Returns the source location where the symbol's implementation lives
Experimental tools lack justification and minimal descriptions. 'get_unhandled_notifications' (48 chars) and 'get_unhandled_requests' (65 chars) are below the 100-char baseline and provide no context on when/why to call them. These appear to be debugging tools, not user-facing capabilities.
No pagination or result limiting documented. Completion can return hundreds of items, find_references could span thousands of usages, and get_symbols recurses into nested structures. Tools lack limit/offset/cursor parameters and result caps, risking context window exhaustion.
Tool 'go_to' combines three operations (definition, type definition, implementation). This violates single-responsibility principle and forces LLMs to parse separate text blocks instead of structured results. Consider keeping specialized go_to_* tools as primary interface.