Loading ToolBench
MCP server for code analysis and symbol discovery across multiple programming languages using tree-sitter
Arbor provides 10 well-intentioned code analysis tools with consistent naming (verb-starting, action-oriented) and universally populated descriptions. However, significant gaps in schema completeness, parameter documentation, and output structure prevent a higher score. All tools are READ_ONLY and lack error recovery guidance. Input schemas are present but sparse, most parameters lack detailed constraints, ranges, or format specifications. Output schemas are not documented in the visible source. The tool descriptions are adequate (60-120 chars) but lack dependency hints, prerequisites, or explicit guidance on when to use one tool vs. a similar one (e.g., 'symbol' vs. 'search'). No tool has input validation rules, enum constraints, or error handling patterns visible in the definitions.
Get a boot summary of the project including name, facets detected, and node count
Get a compact skeleton view of the codebase with optional path filtering, truncation, and grouping
Find all definitions of a given symbol across the codebase
Analyze dependency graph for a symbol showing what it depends on or what depends on it
Get a summary of a specific file including all symbols defined in it
Find all references to a given symbol in the codebase
Search for symbols or files by name or pattern
No output schemas documented. Tool descriptions state what they return in prose ('Get a boot summary', 'Get detailed information'), but no structured schema is visible for LLMs to understand result structure, field types, pagination, or chaining identifiers.
Parameter descriptions lack detail on constraints, ranges, defaults, or examples. 'symbol' parameter says 'Symbol name to search for' but does not explain: Is it case-sensitive? Can it be a partial match? What happens if no symbol matches? 'depth' on skeleton says 'Max nesting depth (default 3)' but omits minimum/maximum bounds.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Get a tree skeleton view of the codebase with optional path filtering and depth control
Read the source code of a symbol with line numbers and context
Get detailed information about a specific symbol including its definition, location, and associated metadata
No enum constraints on parameters that accept discrete values. 'direction' on dependencies explicitly declares enum=['outgoing', 'incoming'], which is good, but other parameters like 'symbol' or 'query' are free-form strings with no validation guidance, LLMs could pass invalid patterns.
Similar tool names risk LLM confusion. 'symbol' (get info on one symbol), 'definitions' (find all definitions), 'references' (find all references), and 'search' (search by name/pattern) all retrieve symbol data but differ subtly. Descriptions do not clearly disambiguate when to use each.
No error handling patterns documented. Tools do not describe what happens on invalid input (e.g., symbol not found, invalid path, malformed query). LLMs receive no recovery guidance, should they retry, call search() first, or fail?
No pagination documentation. Tools like 'search' and 'references' can return unbounded result sets (search has 'limit' param defaulting to 20, but what if there are 1000 matches? No mention of cursor, offset, or total count in the tool description).
Parameter descriptions lack dependency hints. skeleton() accepts both 'path' and 'depth' but does not say: 'If you only know a partial path, use search() first.' Tool chaining is left implicit.