Loading ToolBench
A deterministic, high-precision code intelligence MCP server using Progressive Disclosure routing (Git data → AST data + hybrid retrieval → Semantic/Fuzzy logic)
The code-memory server has well-structured tool definitions with clear, action-oriented names and comprehensive descriptions that guide LLM usage. Most tools follow the verb_noun pattern and include prerequisite guidance. However, several critical issues limit the score: (1) Input schemas are partially visible but incomplete, parameter type information is shown for some but not comprehensively documented in the source excerpt; (2) Output schemas are not documented in the visible source code, making it impossible for agents to plan downstream operations; (3) Error handling and recovery guidance are minimal, tools hint at unindexed state but don't return structured error objects with actionable next steps; (4) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite index_codebase clearly being destructive/mutating. The descriptions are strong (averaging 180-220 chars, well within the 10-1024 guideline), and naming is excellent, but missing output schema documentation and error classification rules place this in the 'good but incomplete' tier.
USE THIS TOOL to check if the codebase has been indexed and whether search tools will return results. Call this BEFORE search_code or search_docs if you're unsure about indexing state. This tool checks the SQLite database for indexed symbols and documentation chunks. It's a lightweight diagnostic - much faster than re-indexing.
USE THIS TOOL to get comprehensive statistics about the code index. This tool provides detailed metrics about the index health, including file counts, symbol distributions, embedding model info, and database size.
CRITICAL: MUST call this before using search_code, search_docs, or search_history. Indexes all code files and documentation in a directory using AST parsing and embeddings. Indexing is incremental - unchanged files are automatically skipped.
USE THIS INSTEAD OF grep/glob/find for ANY code search. This tool provides SEMANTIC code understanding - it finds related concepts, not just text matches. Uses HYBRID RETRIEVAL (BM25 keyword search + dense vector semantic search with Reciprocal Rank Fusion). PREREQUISITE: This tool requires indexing. If results are empty or you haven't indexed this session, call index_codebase(directory) first.
Search documentation and markdown files using hybrid retrieval (BM25 + semantic vector search). Returns relevant documentation sections with context. PREREQUISITE: Call index_codebase(directory) first.
Output schemas not documented in visible source code. LLMs cannot plan downstream tool calls without knowing what fields to expect from search results or index stats responses.
index_codebase tool lacks destructive annotation and explicit error handling for write operations. No documentation of what happens if indexing fails mid-process, whether it's idempotent, or recovery steps.
No tool annotations present. Specifically, index_codebase should have destructiveHint=true to signal it modifies state; check_index_status and search_* tools should have readOnlyHint=true. These annotations help agents reason about side effects and retry safety.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Search Git commit history and file blame information. Three search types: commits (search commit messages), file_history (commits affecting a file), blame (git blame with line-level attribution).
Error handling returns hint strings appended to responses (e.g. _HINT_CODE_NOT_INDEXED) rather than structured error objects with classification and recovery guidance. Agents cannot distinguish 'no results' from 'not indexed' without parsing text hints.
Parameters lack granular format documentation. E.g. 'directory' parameter accepts 'Path to the project directory' but doesn't specify: must it be absolute? Relative to cwd? Must it exist? These details invite invalid input from LLMs.
search_code and search_docs tools return hint text about unindexed state but do not enumerate alternative actions (e.g. 'Call index_codebase("/path/to/project") first'). Hints are implied in tool descriptions, not in error responses.