Loading ToolBench
An MCP server for analyzing code repositories using graph-based code representation and static analysis
The server defines 19 code-analysis tools with consistent naming patterns (mostly verb_noun) and reasonable descriptions. However, there are significant gaps: (1) Parameter descriptions are minimal and often lack constraint information; (2) Output schemas are not visible in the provided source, only inferred from response type names; (3) No evidence of error handling guidance, validation rules, or recovery suggestions; (4) The single destructive tool (delete_repository) has no confirmation/dry-run pattern. Naming is generally strong (get_*, find_*, search_*, calculate_*), but parameter depth is inconsistent, some tools accept optional depth/limit parameters without clear bounds or defaults. The server targets code-context analysis, which is a narrow domain, but lacks input validation and error recovery patterns that would make it production-ready.
Calculates cyclomatic complexity for a specific function or class
Removes all graph data for a repository from the database
Finds the call chain between a source and target function
Identifies dead code (unused functions and classes) in a repository with filtering options
Glob matches file paths within a repository
Finds functions by exact name within a repository
Finds functions with cyclomatic complexity above a specified threshold
Returns functions called by a specified function, with traversal depth control
Output schemas are not visible/documented in source code, only inferred from response type names (e.g., CallChainResponse, RepoMapResponse). Cannot verify that responses include necessary chaining IDs or structured fields. Pattern: pattern:response-shaper requires documented output schemas.
Destructive tool (delete_repository) lacks confirmation/dry-run pattern and warning text. Description does not state irreversibility. An LLM could accidentally delete all repository data without a safeguard. Pattern: pattern:confirmation-request.
Numeric parameters (depth, limit, maxDepth, minComplexity) lack documented bounds, defaults, or constraints. LLMs can pass unbounded values (e.g., depth=999999) causing timeouts or resource exhaustion. Baseline rubric requires explicit ranges. Pattern: pattern:constrained-input.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 58 | - | v1 |
Returns functions that call a specified function, with traversal depth control
Returns class hierarchy relationships (inheritance/implementation) with direction and depth control
Returns module/package dependencies for a symbol with traversal depth control
Returns an overview of symbols (functions and classes) defined in a specific file, sorted by line number
Returns all references to a symbol in the codebase
Returns a hierarchical map of repository structure grouped by directory with file statistics and symbol counts
Returns comprehensive statistics about a repository including file, function, class, module, and external reference counts
Returns detailed context for a symbol including its definition, callers, callees, and siblings in the same file
Reads the complete source code for one or more symbols (functions or classes)
Intelligently searches code by classifying the query and dispatching to appropriate search strategy (file, fuzzy, exact)
Searches for code content matching a query string
Parameter descriptions are often minimal (1-3 words) and lack constraint details. Examples: 'repo' = 'Repository name' (lacks format/naming rules), 'query' = 'Search query' (doesn't explain syntax), 'pattern' = 'Glob pattern' (doesn't document glob dialect). Baseline: 72-char average param annotation. Pattern: pattern:tool-description.
No error handling guidance in any tool description. Pattern: pattern:recovery-guide requires descriptions to state what to do if a tool fails (e.g., 'Symbol not found. Try search_code() with a partial name'). Current descriptions omit this entirely.
Semantic ambiguities in search and lookup tools. Examples: find_function says 'exact name' but doesn't clarify case-sensitivity or fully-qualified names; search_code dispatches to multiple strategies but doesn't explain how LLM should interpret results; get_references doesn't specify what counts as a reference. Pattern: pattern:tool-description.
No pagination or result-limit documentation. Tools like get_repo_map, search_code_content, and find_dead_code may return large result sets but descriptions don't mention limits or next_cursor. Baseline rubric: tools returning lists must accept limit/offset and return total counts. Pattern: pattern:paginated-result.
Tool composition relies on implicit symbol name conventions (no guidance on fully-qualified vs. simple names). If get_symbol_context returns a 'name' field, other tools must accept it, but no clear specification of the name format makes chaining unreliable. Pattern: pattern:tool-chain.