Loading ToolBench
Self-hosted mem0 MCP server for Claude Code with persistent cross-session memory, graph knowledge extraction, and Neo4j support
Server provides 11 memory-management tools with HTTP transport via fastmcp. Tool names follow verb_noun patterns (add_memory, search_memories, get_memory, etc.), descriptions are present, and input schemas are properly defined with type information. However, several tools lack output schema documentation, descriptions vary in quality (some generic, some well-detailed), and error handling guidance is minimal. Parameter descriptions generally exist but some lack constraint details (e.g., no mention of valid ranges for 'limit' or 'threshold'). Security annotations (destructiveHint for delete_memory, idempotentHint candidates) are absent. Output formatting is mostly JSON strings rather than structured objects with explicit schemas. Composition is good, tools are focused on single concerns (memory CRUD, search, graph ops), but chaining context is missing (e.g., search_memories doesn't indicate whether results include memory_id for use in update_memory).
Store a new memory. Requires at least one of user_id, agent_id, or run_id.
Delete multiple memories matching a filter.
Delete a specific memory by ID.
Get all relationships for a specific entity (bidirectional). Returns the full entity profile with outgoing and incoming connections. Returns empty result set (not error) if entity not found.
Page through memories using filters instead of search.
Retrieve a specific memory by ID.
Output schemas are missing or not formally declared. Tools return JSON strings (visible in graph_tools.py) but the tool definitions do not document the structure. LLMs cannot plan downstream tool calls without knowing what fields to extract.
Destructive tools (delete_memory, bulk_delete_memories) lack destructiveHint annotation and detailed error recovery guidance. Agents need explicit markers to recognize irreversible operations. No compensation tools (e.g., restore_memory) offered.
Several parameter descriptions lack concrete constraints. 'threshold' range (0.0 - 1.0) is mentioned in text but not enforced. 'rerank' and 'enable_graph' boolean params lack explanation of side effects.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 55 | - | v1 |
List all entities (users/agents/runs) with stored memories.
Conversation assistant with access to memory context.
Search entities by name substring in Neo4j. Returns matching entities and their outgoing relationships. Pass '*' or empty string to list all entities (up to 100). Regular queries use substring matching (up to 25 results).
Semantic search across existing memories.
Modify an existing memory by ID.
Error handling descriptions are minimal. Tools do not guide agents on recovery steps. For example, get_memory does not explain what to do if memory_id is invalid. search_graph returns JSON errors but no actionable next steps.
Tool composition: search_memories does not document whether results include memory_id for chaining to update_memory or delete_memory. get_memories similarly lacks output schema. Agents cannot plan multi-step workflows without knowing what IDs are available in responses.
memory_assistant tool is underspecified. It is unclear whether it maintains state, calls external LLMs, or purely retrieves context. Description does not answer: What does it return? When should agents call it instead of memory_addition tools? What is the input/output format?
No idempotentHint annotations. Tools like add_memory and update_memory should declare idempotency (likely idempotent if keyed by memory_id). Agents rely on these hints to know whether retry loops are safe.