Loading ToolBench
Local memory engine for Claude Code with SQLite FTS5-based episodic and semantic memory storage, retrieval, and audit capabilities. Provides zero-dependency MCP server interface for memory management, event capture, and context-aware search.
CC Agent Brain has 8 tools with moderate to poor schema definition quality. While tool descriptions are present and reasonably detailed (avg ~140 chars), the schema definitions are incomplete: parameters lack explicit type information in most cases, input validation is missing, and error handling guidance is absent. The tools operate on a SQLite append-only event/memory system, but the interface does not guide LLMs on when to use each tool, how to handle failures, or what output to expect. Tool naming is reasonable but not verb-first consistently. Most critically, there is no visible input schema validation, no documented output schemas, no error recovery guidance, and no security/permission gates despite WRITE operations on sensitive memory data.
Audit memory health and consistency: detect duplicate active memories, broken supersede chains, stale entries, low confidence memories, and undistilled event backlog
List candidate events for memory distillation (events not yet converted to long-term memories) filtered by age and kind
Record an event (user prompt, assistant response, tool call, or system action) into the append-only event stream with optional tags and source attribution
Initialize a new brain database with schema, tables, and FTS indexes
Add, retrieve, update, or list long-term memories with bi-temporal validity, status tracking, and confidence levels across working, episodic, semantic, and procedural layers
Full-text search (FTS5/BM25) over events and memories using free-form query, with optional k nearest results and human-readable output format
Input schemas lack explicit type definitions for parameters. The 'tags' parameter in 'event' is listed as string but has no min/max length or pattern constraints. The 'action' parameter in 'memory' is string but should be an enum ('add', 'get', 'update', 'list', 'retire', 'supersede'). Enums are self-documenting and prevent hallucinated values.
No documented output schemas. Tools return results but LLMs have no guidance on what fields to expect (e.g., does 'memory' return an ID? a timestamp? confidence score?). This forces LLMs to guess structure and breaks downstream tool chaining.
No error recovery guidance. Tool descriptions do not tell LLMs what to do if a memory lookup fails, if a supersede chain is broken, or if confidence is too low. Error responses must include 'what went wrong' + 'what to try next'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Start a JSON-RPC over stdio MCP server exposing event, memory, search, stats, and audit commands
Retrieve aggregated statistics about stored memories and events including counts by layer, status, and temporal distribution
'memory' tool combines six operations (add, get, update, list, retire, supersede) into one tool. This violates single responsibility. LLMs must reason about which action to invoke. Split into separate tools: add_memory, get_memory, update_memory, list_memories, retire_memory, supersede_memory. This also clarifies naming per the pattern:tool standard.
WRITE operations (event, memory, init) lack permission gates and audit trails. Code does not show access control or who/what called these tools. For a system storing agent memories, this is a compliance gap. Every WRITE must log caller, timestamp, and action.
Parameter descriptions lack constraint details. 'body' in memory has no max length specified, can it be 1MB? 1GB? 'confidence' is 'high|medium|low' but this is stated as enum values, not as a schema constraint. 'scope' is 'project|global' but schema does not enforce this. Apply JSON Schema enum or pattern fields.
serve-mcp tool description is vague ('Start a JSON-RPC over stdio MCP server'). Tool names starting with 'serve-' are uncommon and confusing, is this an action the agent should invoke, or an infrastructure setup? This tool should not be exposed as a callable tool; it should be server startup logic.
init tool modifies state (creates database schema) but is exposed as a callable tool. Destructive operations should support dry-run or confirmation. No parameter for --dry-run. Agents could accidentally re-initialize a production brain database.
stats and audit tools have minimal descriptions (50 - 60 chars). 'Retrieve aggregated statistics...' and 'Audit memory health...' do not explain WHEN to call these tools vs other tools, or what format the output takes. Descriptions should be 50 - 200 chars with discovery context.