Loading ToolBench
Long-term memory system for AI assistants — persistent, searchable, self-organizing memory powered by semantic search, knowledge graphs, and reinforcement learning
AIMemory provides 9 well-named, verb-prefixed tools with complete input schemas and category descriptions. Tool names follow verb_noun convention (memory_save, memory_search, memory_update, memory_delete, memory_get_related, memory_pin, memory_unpin, memory_stats, auto_search). All tools have descriptions ranging from 44-366 characters. Input schemas are fully defined with proper JSON Schema types and per-parameter descriptions. However, descriptions are inconsistently detailed, some (auto_search) are lengthy and explanatory, others (memory_pin, memory_unpin) are terse. Output schemas are NOT documented in the provided source, which is a significant gap for LLM reasoning. Parameters like 'depth' (in memory_get_related) lack explicit range constraints in descriptions. No error handling patterns are visible (recovery guides, error classifications). Parameter relationships (e.g., immutable memories cannot be deleted) are stated but could be more explicit in descriptions. The tool composition is sound, each tool has one clear responsibility and names are unambiguous. Overall, solid foundational quality held back by missing output schema documentation and minimal error guidance.
Automatically retrieve and compose relevant memories for a user message. Searches the memory store, selects the most relevant memories, and composes them into a context string within the token budget using multi-resolution levels (full text, summary, entity triple). This tool should be called at the beginning of every conversation turn to inject relevant memory context.
Delete a memory from the knowledge graph. Cannot delete immutable memories. Automatically cleans up graph edges.
Get memories related to a given memory via graph edges (BFS traversal).
Pin a memory to protect it from the forgetting pipeline.
Save a new memory to the knowledge graph.
Search memories by semantic similarity.
Output schemas are not documented. LLMs cannot infer what fields memory_save, memory_search, auto_search, and other tools return. This forces agents to guess at response structure and breaks downstream tool composition.
Descriptions for memory_pin and memory_unpin are very terse (45 chars). According to baselines, descriptions should be 50-200 chars to provide sufficient context for LLM tool selection. Current descriptions lack information about side effects and use cases.
Parameter 'depth' in memory_get_related has a max of 3 but no min is stated in the description. Numeric parameters should specify valid ranges (min, max) directly in the description.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Get statistics about the memory store: total count and category breakdown.
Remove pin protection from a memory, allowing it to be forgotten over time.
Update an existing memory's content and/or keywords.
memory_delete states it cannot delete immutable memories, but this constraint is not reflected in parameter descriptions or error handling guidance. No recovery path is offered if deletion fails.
No error handling patterns visible (error classification, recovery guidance, actionable error messages). If memory_search returns no results or memory_update fails, LLM has no recovery guidance.