Loading ToolBench
An MCP server for persistent memory management using PostgreSQL and vector embeddings. Stores, searches, retrieves, and manages memories with semantic similarity search, distillation of Claude Code sessions, and behavioral pattern extraction.
claude-memory demonstrates solid definition quality with consistent tool naming, comprehensive parameter schemas, and well-structured descriptions. All 10 tools follow verb_noun conventions (save_, search_, get_, update_, delete_, list_). Parameter descriptions are detailed and include format guidance. However, output schemas are not explicitly documented in the code (inferred from implementation), and error handling lacks actionable recovery guidance. Tool composition is excellent, each tool has a single responsibility and clear chaining potential.
Soft-delete a memory by marking it deleted_at timestamp. Memory remains in database for audit trail.
Retrieve a specific memory by ID.
List all distinct projects with memory counts, ordered by count descending.
Get aggregate statistics: active/deleted memory counts, project count, average content length, and storage estimate.
List all tags across active memories with their usage counts, ordered by frequency descending.
List all active (non-deleted) memories with optional filtering by project, date range, or tags.
Save a memory with semantic embedding. Returns the memory ID and confirms storage.
Output schemas not explicitly documented. Response structure inferred from implementation comments rather than formal schema declarations. LLMs cannot plan downstream operations without knowing what fields to expect (e.g., does search_memories return cosine_score or similarity_rank? Are results paginated?).
Error handling lacks actionable recovery guidance. Code returns generic RuntimeError messages like '_DB_UNREACHABLE' and '_DB_BUSY', but tool responses do not guide the LLM on next steps (e.g., 'Try again in 30 seconds' or 'Check connection status'). Per pattern:recovery-guide, errors must tell the agent what to do next.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 17 | - | v1 |
Semantically search memories using vector embeddings. Returns the most similar memories ranked by cosine similarity.
Check if new content is similar to existing memories and suggest an update instead of creating a duplicate.
Update a memory's content, tags, or both. Re-embeds updated content.
Discovery tools (get_projects, get_tags, get_stats) have minimal descriptions. 'List all distinct projects...' and 'List all tags...' lack guidance on WHEN to call them or what structure they reveal.
list_memories accepts date range filters (start_date, end_date) as ISO strings but parameter descriptions do not specify required format or how partial dates are handled.
Irreversible operation (delete_memory) performs soft-delete (audit trail) but description does not clarify this is reversible. LLMs may assume hard-delete and refuse to call the tool. Description should state 'Soft-delete (reversible via recovery process)' to guide safety assessment.
save_memory does not document deduplication behavior. Code references GUARD_NOOP_THRESHOLD and GUARD_UPDATE_THRESHOLD, implying automatic deduplication. LLMs need to know: Will identical content be rejected? Will very similar content trigger an update suggestion instead of creating a duplicate?