Loading ToolBench
MCP adapter for agent-memory: a local-first long-term memory runtime with tools for recording, recalling, and managing memories
Server has 9 well-structured tools with complete JSON schemas and consistent naming (verb_noun pattern: memory_recall, memory_read, memory_record, etc.). All tools have descriptions and input schemas with typed parameters. However, descriptions are terse (10-50 chars, well below the 194-char baseline), parameter descriptions lack context about constraints and use cases, and output schemas are not documented. Error handling guidance is absent, tools do not explain what to do on failure or how to recover. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (READ_ONLY, WRITE, REVERSIBLE). Parameter descriptions are minimal; e.g., 'Search query' and 'Memory name' lack guidance on format, length, or valid values. No documentation of output structure, pagination, or chaining IDs for downstream tools.
Update a memory in place, or supersede it with a newer one.
End a named memory's validity while retaining historical evidence.
Raise or lower a memory's weight explicitly.
Combine named active memories atomically and retain their history.
Read one memory at a chosen level of detail.
Search the memory store and return an L0 list of candidates.
Write one memory into the store.
Tool descriptions are critically short (10 - 50 chars vs. 194-char baseline). LLMs cannot determine when to select memory_supersede vs memory_correct, or memory_trace vs memory_read. Descriptions must explain WHAT the tool does, WHEN to use it, and any prerequisites.
Parameter descriptions lack actionable constraints. 'Search query' does not explain format, length, or valid syntax. 'Memory name' does not clarify naming rules or case sensitivity. LLMs cannot validate input without explicit constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2025-06-18+ | v2 |
End an old memory's validity in favor of an existing active memory.
Read only the archived messages cited by a named memory.
No output schemas documented. LLMs do not know what fields memory_recall returns, whether results are paginated, or what IDs are needed for downstream calls (e.g., does memory_read need the exact name returned by memory_recall?). This breaks tool chaining.
No tool annotations despite clear risk levels. memory_delete and memory_supersede are marked REVERSIBLE but lack destructiveHint. memory_recall and memory_read are READ_ONLY but lack readOnlyHint. Agents cannot distinguish safe from dangerous operations.
No error handling guidance. Tools do not explain what to do on failure (e.g., 'Memory not found, try memory_recall() to search for similar names'). Agents cannot recover from errors without explicit recovery paths.