Loading ToolBench
Local MCP code-intelligence for AI coding tools: surgical search/read/edit, agent-config version history, path-level access + masking guards, and a multi-project hub.
15 tools with complete schemas and descriptions, but quality is uneven. Most tools have adequate naming (verb_noun pattern) and descriptions (50-200 chars), but parameter descriptions are sparse or missing. Output schemas are not documented. Error handling is absent, no recovery guidance, no actionable error messages. Tools like c3_search and c3_read have good descriptions but lack parameter-level detail. Memory/fact tools (search_facts, query_memory) are well-named but descriptions don't explain when to use each vs. the other. No tool declares permissions or security boundaries. Composition is reasonable, tools chain logically (list_projects → query_memory → c3_read), but no pagination guidance in list tools.
Cross-project daily activity digest: sessions, tool calls, edits, git mutations, and token/cost across ALL projects (or one, via project_path). Defaults to today (UTC); pass date (YYYY-MM-DD) or since/until. Set narrate=true to add an LLM prose summary.
Deep LLM-powered analysis of a project's memory patterns and themes (uses the local Oracle model).
Token-efficient structural map of a file (classes/functions/imports). Use before c3_read.
Query a project's memory (read-only actions: recall, query, list, score, graph).
Read exact file content from a project, optionally narrowed to symbols or line ranges.
Code-intelligence search within one project. Use to find which files/symbols are relevant.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., what does analyze_project return? what fields does activity_report include?). Agents must guess structure.
No error handling or recovery guidance. Tools lack actionable error messages. If c3_read fails on a file, the LLM gets no hint to try c3_compress first or check c3_validate. No categorization of retryable vs. fatal errors.
Parameter descriptions are sparse or missing. 'project_path' appears in 10+ tools but is described identically ('Absolute path to the target C3 project'), no guidance on format, validation, or what happens if invalid. 'query' in search_facts says 'Keyword query (space-separated terms)' but doesn't explain boolean operators, case sensitivity, or max length.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Code-intelligence search across ALL projects (or a scoped subset). No project_path needed.
Project health/budget/sessions overview.
Syntax/type validation on a file in a project.
Get cross-project insights. Omit project_path for all insights, or pass it to filter to one project.
List all registered C3 projects with paths and fact counts. Start here to discover what is available.
Run a health check on a project's memory: status, issues, and stats.
Search or list durable memory facts within ONE project.
Get memory-graph statistics for a project (node/edge/type counts).
Search durable memory facts across ALL projects. Returns matches with their source project.
Ambiguous tool selection. search_facts, query_memory, and c3_search_cross all search code/facts but with different scopes and semantics. Descriptions don't explain when to use each. LLMs will guess wrong and waste calls.
No pagination or result limits documented. list_projects, search_facts, and activity_report may return large result sets. No mention of limit defaults, max values, or next_cursor/offset patterns. Agents risk context window exhaustion.