Loading ToolBench
Zero-dependency AST-driven semantic router for Claude Code. Extracts repo structure, signatures, and function bodies via MCP protocol.
OptiVault exposes 4 tools with explicit MCP registration in src/mcp/server.ts. All tools have descriptions and declared input schemas using Zod. However, there are significant gaps: parameter descriptions are minimal or missing, output schemas are not documented, error handling lacks recovery guidance, and tools violate single-responsibility principle. The server exhibits intermediate quality with room for improvement in parameter clarity and error messaging.
Compressed signatures + deps for one file. Use AFTER query_graph has identified the relevant file. Never use as exploration; use as confirmation.
Surgically extract the raw source of a specific function — minimum viable read. Banned as an exploration tool; only use when you know the exact function name from a prior skeleton or graph call.
Bird's-eye structural map of the repo. Call this first if you've never queried the graph in this session; otherwise prefer query_graph for specific traversal questions.
MANDATORY after every surgical write. Triggers a single-file AST re-parse — updates the skeleton and patches the RepoMap in ~20ms. Step 3 of the verification loop: Read → Write+Verify → Sync. Never skip this.
Output schemas undocumented. No explicit documentation of what fields read_repo_map, read_file_skeleton, read_function_code, or sync_file_context return. LLMs cannot plan downstream tool calls without knowing output structure.
Parameter descriptions are sparse or absent. read_repo_map has {} with no parameters but no explanation of why. read_file_skeleton's 'filename' parameter lacks format examples ('src/auth.ts' is in the description but not as a constraint). read_function_code's 'functionName' parameter has no guidance on expected format (method name? full path? signature?).
Error handling lacks recovery guidance. Errors return generic messages ('Graph store not found. Run "optivault init"') without actionable next steps for the LLM. No categorization of retryable vs. fatal errors. No guidance on when to prompt the user vs. when to retry automatically.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Violated single-responsibility principle. sync_file_context is documented as 'MANDATORY after every surgical write' and 'Step 3 of the verification loop: Read → Write+Verify → Sync', indicating it enforces multi-step orchestration logic. Tools should not dictate workflow; the agent should. Split this into orthogonal read and write tools.
read_file_skeleton and read_function_code descriptions state 'Never use as exploration' and 'Banned as an exploration tool', implying they are discovery tools but with gatekeeping constraints. This conflates tool capability with agent policy. Tool descriptions should state what they do, not how the agent should use them.
No pagination or limit constraints documented. read_repo_map returns a full markdown summary with no guidance on size or whether it is capped. For large repos, this could blow the context window. No mention of result limits or cursor-based pagination.