Loading ToolBench
DB-as-source-of-truth memory system for AI agents (MCP server, stdio)
Cerebrium defines 16 tools with explicit schemas and descriptions. All tools have non-empty descriptions (range 50 - 500+ chars) and input schemas with typed properties. However, many parameter descriptions are minimal or generic ('The id from session_start'), and output schemas are not documented. Error handling is basic (try/catch with message wrapping). Tool naming is clear and verb-driven (search, get, write, update, invalidate, link, code_index, code_lookup, etc.), following the verb_noun pattern well. Composition is sound, each tool has a single responsibility. The main gaps: (1) parameter descriptions lack detail on constraints, formats, and valid ranges; (2) no documented output schemas; (3) no error recovery guidance; (4) some parameters like 'limit' lack min/max bounds; (5) descriptions could be more LLM-optimized (currently 50 - 200 chars, which is good, but lack actionable context like 'when to use' and 'what it returns').
Create a checkpoint of the current memory state
Index the owner's source repositories into `symbol` mirror nodes and code edges (defines/imports/calls). Run this AFTER pulling or changing a repo. It is kernel-side and incremental: unchanged files are hash-gated and cost nothing, changed files re-parse and re-embed only the symbols that changed, and files/symbols removed from source are soft-invalidated (never deleted). Pass `repo` (a configured MEMORY_CODE_ROOTS name) or `path` (a directory), or neither to index all configured roots; `force:true` re-parses everything. It does NOT read code back to you — it returns only a compact per-repo summary (files scanned/indexed/skipped, symbols added/updated/invalidated, edges, timing). To read the code afterwards use `search` (by meaning) or `code_lookup` (by structure), then `get` for a symbol's source.
Look up code symbols by structure (qualified name, file path, kind)
Resolve a pending consolidation candidate from `consolidate_suggest`. reject dismisses it (the exact cluster is never re-proposed). accept applies it: a `link` candidate writes the system similar_to edge between its members; a `distill` candidate writes a durable semantic fact from its `override` (or its generated proposal), links it `derived_from` each source, and stamps the sources consolidated; a `merge` candidate folds the duplicate into the canonical survivor — optionally rewriting it from `override`/proposal — re-points authored edges, and supersedes the loser; a `prune` candidate soft-invalidates a dead mirror node. Superseded/consolidated/pruned nodes stay queryable via history. Idempotent per candidate — one already applied or dismissed cannot be resolved again.
Output schemas not documented. Tools return JSON-wrapped results but LLMs cannot infer response structure (fields, types, pagination). Forces agents to guess what data is available.
Parameter descriptions lack actionable constraints. 'limit' has no min/max bounds; 'query' has no length guidance; 'kind' (edge type) has no enum or examples. LLMs cannot validate inputs before calling.
Error handling is generic. All errors return a plain message string wrapped in isError:true. No recovery guidance, no error classification (retryable vs user-fixable vs fatal), no invalid-value echoing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Suggest consolidation candidates (duplicates, distillations, merges, pruning)
Retrieve a memory node by id with full content and metadata
Soft-invalidate a memory node (mark as obsolete without deletion)
Create an edge between two memory nodes (relationship/reference)
Check sync status of a mirrored source
Create or update a mirror node from an external source
Search memory by semantic meaning using embeddings and optional reranking
Start a new session for memory operations
Register an external source (URL, file path, or API endpoint) for mirroring
Get memory system statistics (node counts, embedding queue depth, etc.)
Update an existing memory node's content
Write a new memory node (semantic fact, code symbol, or mirror)
Descriptions lack 'when to use' context. E.g., 'Soft-invalidate a memory node' does not explain when to call invalidate vs delete, or what 'soft-invalidate' means to an agent. Descriptions should guide tool selection.
session_id parameter is marked 'auto-created if unknown' but no tool documents how to obtain a session_id or what happens if one is omitted. Agents cannot determine if session_id is required or optional.