Loading ToolBench
Persistent memory for agents and humans. Store, search, and discover patterns across persistent context.
Cairn MCP demonstrates solid tool organization with clear semantic memory patterns. All 10 tools have well-structured JSON schemas with typed parameters and descriptions. However, descriptions vary in quality, some are action-oriented and specific (e.g., search_memories, store_memory), while others are generic (e.g., list_projects, system_status). Parameter descriptions are consistently present but some lack detailed format guidance. No tool annotations (readOnlyHint/destructiveHint) are present, and output schemas are not explicitly documented. Error handling and recovery guidance are absent. The schema quality is high (proper JSON Schema structure, types, required fields), but descriptions could be more LLM-optimized per the 10-1024 character and discovery-hint pattern.
Create a new work item (epic, task, or subtask).
Get behavioral rules and guardrails. Returns rules for the specified project plus global rules.
List all projects in the memory system with their memory counts.
List work items for a project. Supports filtering by status, type, and assignee.
Update, soft-delete, or reactivate a memory. Use search → recall → modify pattern: find the memory first, verify it, then modify.
Get the full content of specific memories by their IDs. Use after search to get details.
Get recent activity across the memory system — what's been worked on, recent decisions, progress, and open work items. Use this when the user asks what's been happening, what we've been working on, or for general orientation.
No tool annotations present (readOnlyHint, destructiveHint, idempotentHint). Agents cannot distinguish safe operations (read) from destructive ones (write, delete) without explicit hints, increasing risk of unintended side effects.
Output schemas are not documented. Tools return structured data but callers have no explicit specification of response fields, types, or shape. This forces LLMs to infer structure and increases errors in downstream tool chaining.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 24 | - | v1 |
Search for memories using semantic search. Returns summaries of matching memories. Use recall_memory to get full content.
Store a new memory in the system.
Get Cairn system health, memory counts, and model information.
Generic descriptions reduce clarity. 'Get Cairn system health, memory counts, and model information' (system_status) and 'List all projects in the memory system with their memory counts' (list_projects) lack context on WHEN to call them or what the LLM should do with the result. Compare to search_memories which includes 'Use recall_memory to get full content', this chains tools and guides planning.
No error handling or recovery guidance. Tools have no documented error conditions, invalid input responses, or recovery paths. E.g., what does search_memories return if the vector database is unavailable? What if recall_memory is passed an invalid ID? Agents have no guidance.
Parameter format guidance is minimal. search_memories accepts 'as_of', 'event_after', 'event_before' with descriptions mentioning ISO 8601, but no pattern constraint or example format is provided. store_memory's 'event_at' and 'valid_until' similarly lack format validation hints. This invites timestamp parsing errors from LLMs.
Pagination limits not enforced or documented for list tools. list_work_items has a default limit=20 but no explicit max or guidance on iterating through large result sets. search_memories has limit=10 default but no max documented.
modify_memory action parameter is a free-form string (update, inactivate, reactivate) with no enum constraint. LLMs can hallucinate invalid actions like 'delete' or 'archive'. This should be an enum.
list_work_items and create_work_item accept 'item_type' (epic, task, subtask) but parameter descriptions lack clarity on hierarchy rules. Can a subtask reference an epic directly, or only a task? Undocumented dependencies invite misuse.