Loading ToolBench
An MCP server that provides language server protocol capabilities for code analysis, navigation, and editing. It bridges LSP servers (like gopls for Go) with the Model Context Protocol, exposing tools for reading definitions, finding usages, applying text edits, and navigating code.
Dialectic is a Go-based LSP language server with 4 well-defined tools. Tools have explicit names, descriptions, and input schemas visible in tools.go. However, there are significant gaps: (1) Output schemas are not documented, callers cannot predict what fields will be returned; (2) Parameter descriptions exist but are sometimes verbose and lack actionable constraints (e.g., no enum for edit types, no line number bounds); (3) Error handling is basic, tools return generic error messages without recovery guidance; (4) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic differences (apply_text_edit is destructive; read_definition and find_* are read-only). Naming is strong (verb_noun convention followed). Tools are composable and single-responsibility. The server targets Go code analysis, which is a useful domain, but lacks the polish expected of production-grade agent tools.
Apply multiple text edits to a file.
Finds the implementation (definition) location of a symbol in your code. This is a wrapper around the LSP textDocument/definition method that navigates to where a symbol is defined. Symbols include: functions, methods, classes, types, structs, interfaces, variables, constants, properties, fields, enums, packages, or any named entity in your code. Like find_usages, this tool uses a robust approach to locate the symbol: - Provide the file path and line number where the symbol is used - Instead of column position, provide the text that appears before the symbol Example: Suppose you have this line in 'consumer.go' at line 7: 'message := HelperFunction() ' And you want to find where 'HelperFunction' is implemented. You would provide: - filePath: 'consumer.go' - lineNumber: 7 - symbol: 'HelperFunction' - lineContentBeforeSymbol: 'message := ' The tool will return the exact location where HelperFunction is defined, including: - The file path containing the definition - The line and column numbers - A preview of the definition line
Finds all usages (references) of a specific symbol at a specific location in your code. This is a wrapper around the LSP textDocument/references method that finds all references to a symbol. Symbols include: functions, methods, classes, types, structs, interfaces, variables, constants, properties, fields, enums, packages, or any named entity in your code. Since LLMs are not good at specifying exact column positions, this tool uses a more robust approach: - Provide the file path and line number - Instead of column position, provide the text that appears before the symbol on that line Example: Suppose you have this line in 'myfile.go' at line 10: fmt.Println(iface.Foo()) And you want to find all usages of 'Foo'. You would provide: - filePath: 'myfile.go' - lineNumber: 10 - symbolName: 'Foo' - lineContentBeforeSymbol: 'fmt.Println(iface.'
Output schemas are not documented. Callers cannot predict what fields each tool returns, forcing LLMs to guess downstream field names and types.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic roles. apply_text_edit is destructive and should be marked as such. read_definition, find_usages, and find_implementation are read-only and should be annotated.
Error responses lack actionable recovery guidance. Example: 'failed to apply edits: %v' does not tell the LLM whether the error is retryable, user-fixable, or fatal. No suggested next steps.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
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.
Numeric parameters (lineNumber in find_usages, startLine/endLine in apply_text_edit) lack min/max bounds. No specification of valid ranges (e.g., line numbers >= 1, edit line order constraints).
Descriptions for find_usages and find_implementation are verbose (300+ chars) with embedded example walkthroughs. These are helpful for documentation but waste tokens in LLM context. Shorten to 150-200 chars and move examples to separate docs.
The 'edits' parameter in apply_text_edit is an array of nested objects with inline schema. No specification of: (a) max array length to prevent context overload; (b) whether edits are applied sequentially or in parallel; (c) how overlapping edits are handled; (d) whether newText can be null/empty to delete lines.