Loading ToolBench
MCP Memory Server with persistent, semantic memory for LLM agents
The server has 8 tools with varying quality. Naming is generally clear and verb-based (memory_initialize, memory_store, memory_retrieve, etc.), following verb_noun conventions well. Descriptions are present and substantive, most exceed 100 characters with context about WHEN to use tools. However, several critical gaps exist: (1) Input schemas are partially visible in the provided code but not exhaustively documented for all tools; (2) No output schemas are documented anywhere, LLMs cannot predict what these tools return; (3) Error handling guidance is minimal, no recovery instructions or actionable error messages shown; (4) Two destructive tools (memory_initialize with reset=true, memory_delete) lack confirmation patterns or dry-run support, violating pattern:confirmation-request. The server scores well on descriptions and naming but fails on output documentation and error patterns, landing in the C+ range.
Get memory system status and statistics.
List all available topics/knowledge domains in the memory system.
Delete a memory item. Permanently remove a stored memory. Use this to clean up outdated or incorrect information.
Initialize or reset the memory system databases. Rarely needed - the system auto-initializes on startup. Use this only when: - User explicitly requests database reset/cleanup (WARNING: destroys all memories) - System needs manual initialization in special circumstances CAUTION: reset=True permanently deletes ALL stored memories, topics, and summaries from both SQLite and ChromaDB. Use with extreme care and user confirmation.
Retrieve information from memory using semantic search. Search for relevant stored memories by semantic similarity to your query. Use this to recall context, decisions, and facts across conversations.
Store new information in persistent memory for use across conversations. USE THIS PROACTIVELY to create continuity between sessions. Store information when: - User shares preferences, goals, or constraints (coding style, tech choices, requirements) - User corrects you or clarifies their project context - You discover important facts about their codebase, architecture, or patterns - Decisions are made with rationale (why certain approaches were chosen) - User explicitly asks you to remember something ("remember this", "save this") - After completing significant work (architectural decisions, bug fixes, refactors) Examples of what to store: "User prefers functional programming style", "Project uses JWT auth with refresh tokens", "Database migrations via Alembic - never edit directly". The system automatically generates a summary embedding for efficient retrieval.
No output schemas documented for any tool. LLMs cannot predict return values, field names, types, or pagination structure. This forces agents to infer output structure by trial-and-error.
Destructive tools (memory_initialize with reset=true, memory_delete) lack confirmation or dry-run support. Agents can permanently destroy all memories without a safety gate.
Error handling and recovery guidance is absent. No documented error responses, error classifications (retryable vs fatal), or actionable error messages. Agents have no guidance on how to handle failures.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Update an existing memory item. Modify stored memories to correct, expand, or reorganize information. Use this to keep memories current as context evolves.
Generate a summary of memory items. Create summaries of stored memories or search results to understand key points without reading full content.
list_topics and get_status have minimal descriptions (under 80 chars) and no guidance on WHEN to call them.
memory_retrieve lacks pagination parameters (limit, offset, next_cursor). Unbounded results can exhaust context windows. No documented result cap or default limit behavior.
summarize_memory accepts three mutually exclusive parameters (memory_id, query, topic) but no description documents this exclusivity. LLMs may pass multiple simultaneously, causing ambiguous behavior.