Loading ToolBench
Biomimetic memory for personal AI companions. Extract lasting memories from conversations and recall what matters, with self-hosted storage and MCP integration.
The server defines 3 tools with varying quality. Tool schemas are present and properly typed with required field declarations. Descriptions exist but are quite brief (13-60 chars), falling below the baseline median of 194 chars. Parameter descriptions are minimal but present. Schema coverage is reasonable (JSON Schema with types and enums), but descriptions lack the depth needed to guide LLM tool selection effectively. The naming convention is action-verb based (store_, retrieve, delete_), which is good. However, error handling guidance is absent, and output schemas are not documented. No tool annotations (readOnlyHint, destructiveHint) are present despite risk classifications being assigned.
Delete a memory by memory_id and user_id
Retrieve memories based on query text and user_id with optional limit
Store a memory directly with user_id, content, layer, type, and optional ttl_seconds
Tool descriptions are critically brief (13-60 chars vs baseline 194 chars). 'Retrieve memories based on query text and user_id with optional limit' (60 chars) and 'Store a memory directly...' (54 chars) lack actionable context for LLM selection. Per pattern:tool-description, descriptions must explain WHAT, WHEN to use it, and prerequisites.
Output schemas are not documented. The tools return results but the response structure (what fields, types, pagination) is not declared. Per pattern:tool, clients cannot plan downstream calls without knowing what they receive. Example: does 'retrieve' return an array or paginated result? What fields does each memory object contain?
Tool annotations (destructiveHint, readOnlyHint) are missing despite risk classifications being present in the server spec (WRITE, READ_ONLY, DESTRUCTIVE). Per current spec, tool definitions should include these annotations to help clients understand operation safety. delete_memory is marked DESTRUCTIVE but has no destructiveHint in schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2025-06-18+ | v2 |
retrieve tool has ambiguous naming. 'retrieve' alone is generic and lacks context (retrieve what? from where?). Per pattern:tool, names should be verb_noun (e.g., search_memories, get_memories). This causes confusion about when to invoke it vs other potential lookup tools.
Error handling does not provide recovery guidance. No documentation of what errors are retryable, what is user-fixable, or what is fatal. Per pattern:recovery-guide, error responses should tell the LLM what to do next (e.g., 'User not found. Try search_users() with a partial name.').
Parameter 'limit' in retrieve has no bounds declared (min/max). Without bounds, LLMs may pass absurd values (0, -1, 10000) that break the API or timeout.
Idempotency is not declared. Per pattern:idempotent-operation, agents retry on failures. store_memory_direct must clarify: does calling it twice with identical params create one memory or two? Without idempotency guarantees, agents risk duplicate data.