Loading ToolBench
MCP servers providing codebase analysis tools (semantic search, symbol indexing, memory management) and tools for code exploration, definition finding, reference tracking, and repository memory operations.
This server provides 9 codebase analysis tools with mostly complete schemas and descriptions. However, several tools lack descriptions or have descriptions under 20 characters, which violates critical rubric requirements. Parameter descriptions are present but often generic. No tool annotations (readOnlyHint/destructiveHint) are visible. The memory_write tool performs state modification but lacks explicit guidance on idempotency or error recovery. Overall, the server falls into the 'D' (Poor) range due to missing descriptions on some tools and lack of structured error handling guidance.
Find where a symbol (class, function, method) is defined. Uses the cached tag index from SymbolIndex. Supports tree-sitter and regex-extracted tags.
Find all references to a symbol throughout the codebase.
Return the minimal context needed to understand a symbol (imports, related symbols, docstring, signature).
Get a high-level overview of a file's purpose, structure, and main symbols without reading raw content.
Estimate the blast radius of a change to a symbol (what depends on it, what it depends on).
Read memory files from repository memory directory. Lists all files if no path provided, or reads specific file content.
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint). The memory_write tool is destructive/state-modifying but lacks explicit annotation. Agents cannot distinguish safe read-only tools from state-changing ones.
memory_write lacks explicit error handling guidance. No mention of what happens on write conflicts, disk full, permission errors, or invalid paths. Tool description does not guide LLM on recovery or retry strategy.
get_impact description is vague ('Estimate the blast radius of a change'). Does not explain WHAT data is returned, HOW dependencies are computed, or WHEN to call it vs other tools. LLM may not know whether to expect a list of affected files, function calls, or dependency counts.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 17 | - | v1 |
Write content to a memory file in the repository memory directory.
Extract a structural summary (imports, docstrings, function/class signatures, key constants) from a source file without reading the entire contents.
Hybrid search combining semantic (vector) search and keyword (text) search using RRF (Reciprocal Rank Fusion) ranking.
Parameter descriptions are present but generic. E.g. 'Exact name of the symbol to find' does not clarify case sensitivity, namespace handling, or how to find symbols in imported modules. Agents lack disambiguation guidance.
No documented output schemas. Tools like search_codebase, get_impact, and memory_read return structured data but the response format is not specified. LLMs cannot predict what fields to expect or how to chain results to downstream tools.
memory_read accepts optional 'file_path' parameter but does not specify directory traversal restrictions, hidden file filtering, or maximum result size. No guidance on what happens when listing a large directory.
No pagination documented for tools that could return many results (find_references, search_codebase, memory_read). If a symbol is referenced 1000 times, the response could blow the context window.