This Mem0 MCP server demonstrates solid structure with 16 well-defined tools operating on a consistent memory management API. All tools have descriptions (10-20 chars minimum) and explicit JSON Schema input definitions visible in src/index.ts. However, several quality gaps prevent a higher score: (1) Many parameter descriptions are generic and lack actionable guidance (e.g., 'Optional key-value filters for custom logical query composition' does not explain what keys or values are valid); (2) Output schemas are not documented, callers cannot see what fields are returned; (3) Error handling is present but generic; (4) Parameter naming uses aliases (sessionId/runId, content/messages) creating ambiguity; (5) The 'infer' boolean parameter and cloud-only features ('waitForCompletion', 'timeoutMs') lack clear documentation on prerequisites and fallback behavior. Strengths: consistent verb-noun naming (add_, search_, list_, get_, update_, delete_), all tools have descriptions between 50-200 chars, input schemas are detailed with types and enums (e.g., feedback enum in rate_memory), and the design avoids overloaded parameters.
Tools (16)
add_memorywriteauthsource verified77/100
Stores a piece of text or structural messages as a memory in Mem0.
Output schemas not documented for any tool. Callers cannot see what fields are returned, forcing LLMs to guess field names and causing reference mismatches downstream.
Duplicate tool: search_memory and search_memories do the same thing. If search_users and find_users both exist, the LLM wastes reasoning cycles deciding between them.' The backward-compatible alias creates confusion without benefit.
search_memorysearch_memories
Recommendations
Add explicit output schemas for all tools in the ListToolsRequestSchema response. For example, add_memory should document: 'Output: {memoryId: string, status: string, extractedAt: ISO8601}'. Reference the 100% A+ baseline.
Consolidate search_memory and search_memories into a single canonical tool named search_memories. Remove the alias to reduce LLM confusion.
Specify the structure of the 'filters' parameter in search_memories, list_memories, and create_memory_export. Document valid keys (e.g., 'created_at', 'agent_id') and operators (e.g., 'eq', 'gt', 'contains'). Alternatively, replace the generic 'filters' object with explicit optional parameters (e.g., agent_id_filter, created_after, created_before).
Add min/max constraints to pagination parameters in JSON Schema. Example: 'page': {type: 'number', minimum: 1, default: 1} and 'pageSize': {type: 'number', minimum: 1, maximum: 100, default: 10}.
In add_memory, clarify the relationship between 'content' and 'messages' parameters. State: 'Either content (string) or messages (array) required, but not both. If both provided, messages take precedence.' Update schema to enforce this via description.
For destructive tools (delete_memory, batch_delete_memories), add explicit warnings: 'This operation is irreversible. Once deleted, a memory cannot be recovered.' Add a recommended pattern: 'Consider calling get_memory first to confirm the ID.'
Document cloud-only feature fallbacks in the tool description, not just parameter descriptions. Example: 'infer defaults to true (cloud: extracts semantically; local: stores verbatim). customInstructions is cloud-only; ignored on local backends.' Update all three tools (add_memory, search_memories, rate_memory) consistently.
Parameter 'filters' (object type, unstructured) used in search_memories, list_memories, create_memory_export with no schema definition. What keys are valid? What operators? LLMs cannot determine valid values.
Parameter ambiguity in add_memory: both 'content' (string) and 'messages' (array) are optional and semantically different. Description does not clarify precedence or when to use each.
Cloud-only features ('waitForCompletion', 'timeoutMs', 'rerank', 'customInstructions') documented only in parameter descriptions, not in tool description. Fallback behavior for non-cloud backends (local, supabase) is unstated. LLMs cannot determine if a call will succeed or fail based on backend.
Batch operations (batch_update_memories, batch_delete_memories) do not document array size limits.
batch_update_memoriesbatch_delete_memories
Add error recovery guidance to tool descriptions. Example for get_memory: 'If the memory ID is not found, call search_memories() with a relevant keyword. Returns: {error: 'MEMORY_NOT_FOUND', suggestion: 'Try searching by content or agent_id.}'
For batch operations, add array size limits to the description: 'memories array must contain 1-100 items. Partial failures are returned per-item: [{memoryId, status, error}].' Document this in the output schema.
Define the schema for the 'schema' parameter in create_memory_export. Either: (a) provide a formal JSON Schema definition of valid export schema structures, or (b) replace with specific parameters like 'export_format' (enum: ['json', 'csv']) and 'include_fields' (array of field names).
Add a tool description for get_capabilities explaining when to call it ('Call once at startup to detect backend capabilities') and what to do with the output ('Check supported_backends and max_memory_size before calling other tools').
Document whether operations are idempotent. Example: 'update_memory is idempotent, calling twice with the same parameters produces the same result.' This guides agent retry logic.
For list_memory_events, add filtering parameters (memory_id, status, start_date, end_date) to make the tool more useful for discovery. Currently, pagination-only limits its utility.