Loading ToolBench
MCP server that gives AI coding agents structural understanding of a codebase — symbols, references, blast radius, cyclomatic/cognitive complexity, and behavioral-git signals across 14 languages (tree-sitter).
Strong tool definitions with comprehensive descriptions (avg 180+ chars) and well-structured Zod schemas. All 10 tools have explicit registrations with inputSchema, descriptions, and annotations. Tool names follow verb_noun convention (find_symbol, get_context, search_structure). However, output schemas are not documented in the visible code, responses are described narratively but lack formal JSON Schema definitions. Parameter descriptions are detailed and include constraints, but some tools lack enum validation where appropriate (e.g., 'kind' in find_symbol is an enum, good; but 'include' in get_context is an array without item type constraints). Error handling is implicit (tools return results or errors) but recovery guidance is not visible in the definitions. Annotations are present and correct (readOnlyHint, destructiveHint, idempotentHint). Overall: solid definitions with room for output schema documentation and stricter input validation.
'I changed these files — what breaks, and which of my notes are now suspect?' One call over the git working set (uncommitted by default; pass `ref` for committed changes vs a branch/commit). Per changed file: the highest fan-in symbols with their transitive blast radius, staleness-flagged anchored notes, and usual co-change partners.
'Who uses X?' Cross-file callers ranked by confidence (directory + import proximity), not raw text matches like grep — each row tagged [name match] or the weaker [member call]. Rows are AST-derived and confidence-tiered, not compiler-verified — verify before asserting. For the transitive blast radius use impact.
'Where is X defined?' Use instead of grep when you want the definition of a named symbol (exact/prefix/fuzzy) with fan-in, fan-out, and cyclomatic+cognitive complexity — not every text occurrence. Then get_context for the body or find_references for callers. Optional kind/scope/limit filters.
'Discard a note.' Remove a single note by ID (returned by recall), or all notes anchored to a symbol if no ID given. Scoped removal only — source files are never touched.
'Tell me everything about this symbol.' Full body (verbatim), within-file callers/callees, coupling (fan-in/out, cyclomatic+cognitive complexity, blast radius), imports, and any remembered notes anchored here (staleness-tagged ✓/⚠) — plus co-change partners and recent commits when git is available. Reach for this after find_symbol instead of opening the file by hand.
Output schemas not documented. Tool descriptions explain what is returned (e.g., 'Full body (verbatim), within-file callers/callees, coupling...') but no formal JSON Schema is visible for response structures. LLMs cannot plan downstream tool calls or extract fields reliably without documented output types.
get_context 'include' parameter is an array but lacks item type constraints. Description says 'Sections to include: body, callers, callees, coupling, imports, notes, co_changes, git' but no enum or validation is visible. Should be z.array(z.enum([...]))
Error handling and recovery guidance not visible in tool definitions. Descriptions do not state what errors are possible, how to recover, or when to retry. E.g., find_symbol could fail if symbol not found, should guide LLM to try fuzzy search or broader scope.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | <=2025-11-25 | v2 |
'What breaks if I change X?' Transitive upstream caller tree grouped by hop, with a distinct-caller blast count and git co-change partners — something grep can't compute. Each edge tagged by confidence. For direct callers only, use find_references. (Edges are AST name-matches, not compiler-verified — verify before asserting; downstream callees and inheritance are not traversed.)
Start here. 'What is this codebase?' — language breakdown, top-level structure, entry points, symbol counts, and remembered-knowledge counts; in a git repo, also branch/hotspots, risk ranking (churn × coupling × complexity), and index freshness. Orient with this before grepping; then drill in with find_symbol / get_context.
'What do I know about this symbol?' Retrieve all notes anchored to a symbol (file + name + optional line), with staleness tags (✓ fresh, ⚠ stale if the symbol moved or the file changed). Returns markdown.
'Anchor a note to this symbol for later.' Append a note (markdown) to the agent-curated knowledge layer, scoped to a symbol (file + name + optional line). Notes survive index invalidation and are surfaced by get_context (staleness-tagged ✓/⚠). Use for domain knowledge, gotchas, or refactoring TODOs the codebase doesn't encode.
'Find code matching a pattern.' Structural search (AST-based, not text grep) — language-specific syntax patterns with capture groups. Returns file + line + matched text + captures. Supported languages: TypeScript, JavaScript, Python, Java, Go, Rust, C++, C#, PHP, Ruby (others: error). Patterns are language-native syntax (e.g., `function $name() { ... }` for TS/JS).
Pagination not visible in tool definitions. Tools like overview, find_symbol, find_references accept 'limit' but no 'offset', 'page', or 'cursor' parameters. Large result sets could exhaust context window without pagination support.
changes tool accepts 'ref' (git ref) but description does not explain valid formats (branch name, commit hash, tag). Should specify: 'Git ref: branch name, commit SHA, or tag (e.g., main, abc123def, v1.0.0). Defaults to working set if omitted.'