Loading ToolBench
MCP server providing semantic analysis tools for Scala code, including symbol search, refactoring, code navigation, and structural analysis via SemanticDB
ScalaSemantic provides 25 well-named, domain-specific tools for Scala code analysis. Tool names follow verb_noun convention (find_symbol, get_workspace_root, extract_method_plan). All tools have descriptions (avg ~120 chars, within 10-1024 range). Input schemas are present with typed parameters. However, parameter descriptions are sparse or missing for many tools, e.g., 'limit' in find_symbol lacks guidance on valid range; 'contextLines' in find_usages has no description. Output schemas are not documented in the provided source, forcing LLMs to infer response structure. Error handling and recovery guidance are absent. Three tools (rename_plan, move_plan, extract_method_plan) perform reversible refactoring but lack confirmation/dry-run patterns. No tool annotations (readOnlyHint, destructiveHint) are visible. The codebase shows strong semantic analysis capability but weak LLM-facing documentation.
Return source code with semantic annotations (types, symbols, implicit chains)
Plan multiple rename refactorings at once
Find a call path between two methods or functions
Get the class hierarchy (supertypes and subtypes) for a given class symbol
Get the outline (nested structure of types and members) of a Scala source file
Plan extracting a code range into a new method, determining parameters and return values
Find all overloaded versions of a method symbol
Output schemas not documented. LLMs cannot infer response structure for any of the 25 tools. No documentation of return types, field names, or nested object shapes.
Parameter descriptions missing or incomplete. 'limit', 'contextLines', 'detailed', 'graph', 'minSize', 'maxDepth' lack guidance on valid ranges, defaults, or constraints. LLMs cannot validate inputs.
Refactoring tools (rename_plan, move_plan, extract_method_plan) lack confirmation/dry-run patterns. No mechanism to preview changes before applying. Agents cannot safely plan reversible operations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Search for symbols by name across the project index with ranking by exact match > prefix > substring, then by length
Find all usages of a symbol across the project with optional context lines
Get the workspace root directory and coverage information
List all members (methods, fields, nested types) of a class or object symbol
Get the call hierarchy for a method (callers or callees)
Get the signature of a method symbol with parameter and return types
Plan moving a symbol to a different package or owner
Get a filtered outline of a file with query matching, parent context, depth limits, and kind filtering
Refresh the workspace index, optionally triggering a recompile
Plan a rename refactoring for a symbol, showing all affected locations
Resolve implicit parameters and values at a specific position
Plain text search across source files with optional path filtering
Find semantically similar code blocks (smart duplication detection)
Extract and annotate specific source code ranges from files
Analyze the overall structure of the project (modules, dependencies, architecture)
Trace the chain of implicit resolutions for an implicit parameter
Get the type of an expression at a specific position in a file
Trace the data flow of a value at a specific position
No error handling or recovery guidance. Tools do not document failure modes, retryability, or actionable error messages. LLMs cannot self-correct on failures.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe read-only tools from destructive ones. refresh_workspace (WRITE risk) and refactoring tools lack destructiveHint.