Loading ToolBench
Perenna presents a memory management tool suite with clear action verbs and documented schemas. However, several critical quality gaps prevent a higher score: parameter descriptions are inconsistent (memory_read has detailed descriptions, but memory_delete lacks most parameter context); output schemas are not explicitly documented in the source; error handling guidance is absent; and no indication of idempotency, confirmation patterns, or recovery guidance for destructive operations. The tool naming follows verb_noun convention (memory_read, memory_write, memory_delete), which is sound, but lacks the specificity guidance that would help LLMs distinguish use cases (e.g., 'search_memories' vs 'list_memories'). Input schemas are present and properly typed for all three tools, which is a significant positive. The server is in development (alpha), which accounts for some gaps, but production readiness requires addressing the error handling and output documentation issues identified below.
Delete permanent memory
List memories and search for relevant memory by query
Create, update, or upsert permanent memory
memory_delete lacks confirmation or dry-run capability. Destructive operations should support a preview or require explicit confirmation to prevent irreversible data loss when an agent makes a mistake.
No output schemas are documented in the source code. The MCP server definitions show input schemas but do not specify what fields, types, or structure clients should expect in responses. This forces LLMs to guess about downstream chaining (e.g., what fields are returned by memory_read search? are IDs included for follow-up delete calls?).
Error handling lacks recovery guidance. If memory_read fails to find a query result, the tool should suggest alternatives (e.g., 'No memories found for X. Try a broader search or list all memories in scope Y'). Current implementation likely returns bare errors without actionable next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
memory_delete description is 31 characters, below the 50-character minimum for LLM-optimized descriptions. It states WHAT (delete permanent memory) but not WHY (cleanup old knowledge), WHEN (after memories become obsolete), or any prerequisites. This is insufficient for an LLM to decide whether to call this tool.
memory_write description does not indicate that this tool modifies state (creates/updates/upserts permanent records). LLMs need to know which calls are safe to retry and which have side effects. The description should be explicit: 'Creates, updates, or upserts permanent memory records. This is a stateful operation.'
memory_read's 'limit' parameter lacks a documented range. Baselines suggest 1 - 100 for pagination limits. Without explicit bounds, LLMs may pass unreasonable values (0, 10000, negative numbers) that cause failures or performance issues. Add 'limit: The maximum number of results (1 - 100, default 20)' to the description.
memory_read's 'action' parameter description is 'The memory operation to perform', generic and does not explain the semantic difference between 'list' (show all), 'search' (semantic query), and 'get' (by ID). Agents may conflate these. Add: 'Action to perform: "list" retrieves all in scope, "search" runs semantic query, "get" retrieves by memory_id.'
Unclear parameter dependencies and constraints. For memory_read: query is 'required for search action' but the schema does not mark it as conditionally required. LLMs may omit it and get confusing errors. For memory_write: which parameters are required for 'create' vs 'update' vs 'upsert'? The schema does not reflect these dependencies.