Loading ToolBench
Shared long-term memory for MCP agents — one brain, many agents. Standalone embedded runtime: SQLite + FTS5 + exact vector hybrid search, local Harrier q4 ONNX embeddings, self-expiring diary model. No server, container, or daemon required.
Strong tool definitions with comprehensive descriptions and well-structured schemas. All 8 tools have clear, LLM-optimized descriptions (100-300 chars) that explain WHEN to call them and WHAT they do. Input schemas are complete with type definitions and field-level descriptions using Annotated[...Field(description=...)]. Tool names follow verb_noun pattern (remember, search, get, reinforce, forget). Key strengths: excellent parameter documentation, clear lifecycle guidance (search→get, use→reinforce/forget), and domain-specific constraints (importance 1-5, topic kebab-case). Gaps: no output schemas documented in code, no error handling guidance in descriptions, no tool annotations (readOnlyHint/destructiveHint), and audit/health tools lack context on when to call them.
List structural mutations (remember, reinforce, forget, restore, hard_delete) in reverse chronological order. Returns audit events with agent attribution, action, and optional detail. Use this to understand what changed and when.
Soft-delete a memory: mark it deleted and clamp its expiry to the grace window. Call this after you actually use a memory and it proves wrong. Soft deletes can be restored within the grace window; after that, the entry is purged.
Fetch one memory by id — the full record with content, metadata, and timeline context. Call this after search or recent returns a result with has_content=true.
Probe the storage and embedding system without loading the model. Returns a status object with storage health, embedding profile info, and capability flags (sqlite_vec available, etc.). Call this to verify the runtime is ready before using search or remember.
List the newest memories on the timeline, newest first — a pure listing with no query. Use it to catch up on what was stored recently, or to walk one day (timeline_day) or catalog.
Output schemas not documented in tool descriptions. LLMs cannot plan downstream calls or extract fields without knowing what search/recent/get/audit return.
No error handling guidance in descriptions. Tools do not explain what to do if a memory_id is invalid, search returns no results, or storage is unavailable.
Missing tool annotations. No readOnlyHint on search/recent/get/health/audit, no destructiveHint on forget, no idempotentHint on reinforce. Agents cannot infer safety properties.
health and audit tools lack context on when to call them. Descriptions do not explain the typical workflow or prerequisites.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | <=2025-11-25 | v2 |
Extend the life of a memory by renewing its expiry. Call this after you actually use a memory and it proves correct and valuable — the only way an entry's life is extended.
Store one memory as a timeline (diary) entry. Call this when you learn something worth recalling later: a decision, a bug and its fix, a user preference, a fact, a task. The store is append-only: repeating the same knowledge creates a new entry rather than overwriting one, so correcting a memory means remembering the new version and forgetting the old. Do not store secrets, credentials, or large data dumps — store summaries of knowledge.
Search memories by meaning and keywords at once (semantic + full-text, fused). Returns preview lines in relevance order — call get(memory_id) when a result has has_content=true and you need the detail. Search here before answering anything a user may have told an agent before: past decisions, fixed bugs, preferences, project conventions. Text that appears only in a memory's content is findable here even when the meaning does not match, so exact identifiers, paths, and error strings are worth searching for verbatim. Reading changes nothing. After you actually USE a memory, close the loop: reinforce if it proved correct and valuable, forget if it proved wrong.
No pagination guidance in audit description. Tool accepts limit (max 100) but does not explain how to iterate through large audit logs or what next_cursor/offset pattern to use.