Loading ToolBench
indxr is a well-designed codebase indexing tool with solid naming conventions, comprehensive parameter schemas, and clear descriptions. All 26 tools follow verb_noun patterns (find, summarize, read, get_*, list_*). Schemas are complete with proper type definitions and descriptions for all parameters. However, output schemas are NOT documented in the tool definitions, LLMs cannot predict what fields to expect from responses. Error handling guidance is absent, tools don't specify what happens on failure or how to recover. Tool annotations (readOnlyHint, destructiveHint) are missing, though the README indicates read-only semantics. The tool set is well-composed with clear single responsibilities, but some descriptions could be more actionable (e.g., when to use 'find' vs 'search_relevant'). Average tool description length ~140 chars (within 10 - 1024 range). All parameters have type definitions and descriptions, meeting the 100% baseline for A+ tools.
Get summaries for multiple files matching a glob pattern.
Get detailed explanation of a symbol's interface and relationships.
Find symbols, files, or references in the codebase.
Find all callers of a specific function or method.
Get the dependency graph of the codebase.
Get a summary of structural changes since a git reference.
Get context around a specific line or symbol in a file.
Output schemas are not documented. Tool definitions show input schemas but do NOT specify what fields, types, or structure responses contain. LLMs cannot plan downstream calls or extract data reliably when they don't know the response shape.
Error handling guidance is missing. Tools do not specify what errors can occur, whether they are retryable, what the LLM should do on failure, or what information will be provided in error responses. This violates the recovery-guide pattern.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Get a summary of a file's declarations and imports without reading source.
Get codebase health metrics and analysis.
Get complexity hotspots (most complex functions) in the codebase.
Import statements for a file.
Get the public API surface of a file or module.
Find test files related to a given source file.
Get codebase statistics (file count, line count, language distribution).
Estimate token count for a file, symbol, or the entire index.
Directory/file tree of the codebase.
Analyze type flow and data dependencies for a symbol.
List declarations in a file, optionally filtered by kind.
List monorepo workspace members.
Find declarations by name (case-insensitive substring).
Read source code by symbol name or line range. Use symbol to read a specific function/struct, or start_line+end_line for a range. Cap: 200 lines per symbol, 500 total.
Read source code for a symbol or line range.
Rebuild the codebase index from scratch.
Semantic search for relevant files and symbols.
Search function signatures by substring.
Get overview of a file, symbol, or directory without reading source. Pass a file path for file summary, a glob (e.g. 'src/**/*.rs') for batch summaries, or a symbol name (no '/') to explain a symbol's interface.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are absent from the schema. Although the server is mostly read-only (25 of 26 tools), explicitly marking them in JSON Schema would help LLMs understand call safety and avoid unnecessary confirmations. regenerate_index should be marked destructiveHint: true.
Some descriptions are generic and do not clarify WHEN to use one tool vs another. 'find' and 'search_relevant' both search; their descriptions should explain the semantic difference and when an LLM should prefer one. Similarly, 'get_file_summary' vs 'get_file_context' vs 'read' could be clearer on scope and intent.
Some extended tools (get_health, get_stats, get_tree) have minimal descriptions (70 chars or fewer). Expand to 100+ chars to explain what metrics/info they return and when the LLM should call them.