Loading ToolBench
MCP server for querying testigo-recall knowledge bases. Exposes codebase knowledge base as tools that any MCP-compatible AI agent (Claude Code, Cursor, Windsurf, etc.) can call directly. On startup the server automatically downloads the latest knowledge base from supported backends.
This server demonstrates strong definition quality with well-crafted tool descriptions and clear naming conventions. All 6 tools follow verb_noun patterns (search_, list_, get_) and have substantive descriptions (100-300+ characters). Input schemas are present and typed for all tools. However, there are gaps in output schema documentation and some parameter descriptions lack specificity around formats/constraints. The static instructions are exceptionally detailed and guide LLM usage well, but the tool definitions themselves could be more atomic and better document return types. Parameter descriptions are generally good but inconsistent, some tools like search_codebase have excellent guidance about syntax and usage, while others like get_recent_changes lack detail. No explicit error handling patterns are documented in the tool definitions.
Determine the blast radius of changes to a file or service. Shows all dependencies and usages across the codebase.
Deep dive into a specific module to retrieve ALL facts for that module. Use only when you need all facts for a module before editing its code. Do NOT use after search_codebase returned results for the same topic.
Retrieve the most recently extracted facts from the knowledge base.
Query the cross-repo dependency graph from package manifests (go.mod, package.json). Supports direction parameter: 'outgoing' = what this repo depends on, 'incoming' = what depends on it. Use when analyzing impact of changes to shared libraries or understanding system architecture.
List all available repositories and their fact counts. Call with no arguments to see repo names and descriptions. Only call with repo_name parameter on small repos (<100 modules).
Search the knowledge base using keyword matching (FTS5/BM25). Use semicolons to batch multiple searches into one call. Primary tool for querying facts about behaviors, design decisions, and assumptions.
Output schemas not documented for any tool. LLMs cannot plan downstream operations or extract specific fields without knowing what each tool returns. Returning data structures, field names, types, and pagination behavior are completely undocumented.
get_recent_changes and get_component_impact have minimal descriptions (55-65 chars). They lack context about when to use them vs alternatives, what data structure is returned, or how results should be interpreted. Descriptions should be 100-300 chars with clear usage guidance.
Parameters lack specificity about formats, constraints, and validation rules. E.g., search_codebase's 'limit' parameter has no min/max bounds documented. list_modules doesn't explain what 'small repos' means or why the threshold matters. LLMs cannot self-validate without explicit constraints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 20 | - | v1 |
No error handling patterns documented. Tools provide no guidance on what to do if a search returns empty, if a module_id is invalid, if a component is not found, or how to recover. Error responses must tell the LLM what to do next.
No tool annotations present. Tools should declare readOnlyHint (all 6 are read-only), idempotentHint (likely true for most), and any destructive operations. Tool annotations enable safer agent planning and prevent accidental side effects.