Loading ToolBench
Self-contained, deterministic repo-indexing engine: walk + language detection + symbol/import extraction (tree-sitter AST with regex fallback) + import resolution + typed cross-file link-graph + analytics. Ships as a single zero-dependency engine with MCP server integration.
Strong tool definitions with comprehensive schemas and detailed descriptions. All 15 tools have explicit input schemas with typed parameters and descriptions. Tool names follow verb_noun convention (scan_summary, find_symbol, replace_symbol_body). Descriptions average ~150 chars, well within the 10-1024 baseline. However, several tools lack output schema documentation, and error handling guidance is minimal. The write tool (replace_symbol_body) lacks confirmation/dry-run patterns. No tool annotations (readOnlyHint/destructiveHint) visible in source.
Who calls a function? Per-symbol caller index: each defined symbol with the exact (file, line) call sites that bind to it. Omit `name` for the full index.
Per-file git commit counts (whole history, or since a ref) — the churn half of hotspot analysis.
Change coupling: pairs of files that repeatedly change in the same commits — hidden dependencies no import shows. strength 1.0 = every change to one touched the other.
Who references a symbol? Three labeled tiers: defs (declarations), callSites (line-precise, import-corroborated call bindings), referencingFiles (file-level identifier/doc mentions — may include homonyms). Confidence decreases across tiers; the labels let you decide what to trust.
Find symbol declarations by name or name path ('Class/method' matches a method inside Class). Each match carries its COMPLETE SIGNATURE (parameters and return type) by default, because "what shape is it" is the question that follows "where is it" almost every time and one round trip beats two. Options: substring matching, includeBody for the declaration's source, concise to drop everything but name/kind/file/line when you genuinely only want a location. Exact-name matches rank first.
replace_symbol_body (WRITE tool) lacks confirmation/dry-run pattern and minimal error guidance. No description of what happens on ambiguity (multiple matching symbols). Destructive operations need recovery paths.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint) visible in source. MCP spec 2026-07-28 recommends these for agent safety. All read-only tools should declare readOnlyHint=true; replace_symbol_body should declare destructiveHint=true.
Output schemas not documented in tool definitions. LLMs cannot plan downstream calls or extract fields without knowing response structure. find_symbol, callers, symbols, graph all return complex nested objects but no schema is visible.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Build the full typed cross-file link-graph (import/call/use/doc-link/mention edges, module grouping, PageRank centrality, Louvain communities, tests-map). Returns graph.json. Large on big repos — prefer scan_summary/symbols/callers for targeted questions.
Where does work concentrate? Files ranked by git churn × size (commits × log2 lines). High-scoring files are where changes and defects cluster.
Is the optional LSP tier configured, and would it answer? Reports the config path and its source, each server with whether its command is on PATH and how many files in this repo it claims, and the languages no server covers. Opt-in by asset: the tier is active only when <repo>/.codeindex/lsp.json exists (or CODEINDEX_LSP_CONFIG points at one). `probe: true` additionally starts each server to read the capabilities it really advertises. The tier never touches graph.json/symbols.json — it annotates query answers only.
One call that says what this repository IS: its own tagline, size and language mix, monorepo layout when there is one, a token-budgeted map of the highest-PageRank files with their key signatures, and where git says work concentrates. Composes scan_summary + workspaces + repo_map + hotspots so the first four round trips of a session become one, and persists the result as the `onboarding` memory (read_memory) so the next session does not repeat them. Set remember:false to skip the write.
WRITE: replace a symbol's whole declaration with `body` (verbatim, supply full indentation). The symbol is resolved by name path ('Class/method'); ambiguity errors list the candidates — qualify with `file`. Line spans come from the AST index.
Token-budgeted map of the repository: the highest-PageRank files with their key exported signatures, deterministically rendered to fit `budgetTokens` (default 1024). The densest single read to understand an unfamiliar codebase.
Deterministically scan a repository: file count, per-language file histogram, HEAD commit, and whether the walk was capped. Fast first look at any codebase.
Where is a symbol defined and which files reference it? Returns the definition sites (file, line, kind, exported) and referencing files. Omit `name` for the full symbol index.
All symbols declared in ONE file (name, kind, line span, exported, parent), in declaration order — the fastest way to understand a file without reading it.
Detect monorepo packages (npm/pnpm/yarn/lerna/nx/cargo/go.work/maven) with the workspace dependency graph, one cycle if present, and a topological build order.
Error handling lacks recovery guidance. No indication of what LLM should do on 'symbol not found', 'repo not accessible', or 'LSP server unavailable'. Errors should suggest alternatives (e.g., 'Try symbols() without name for full index').
lsp_status description is verbose (>200 chars) and mixes multiple concerns (config detection, server probing, capability reporting). Consider splitting into separate tools or simplifying description for LLM clarity.