Mem0 MCP Server

Official

by mem0ai

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but get_memories and search_memories could cause confusion as both involve retrieving memories with filters, though search_memories adds semantic search. The other tools (add, delete, update, list) are clearly differentiated by their actions on memories or entities.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (e.g., add_memory, delete_memory, get_memories), with clear and predictable naming. There are no deviations in style or convention across the set.
Tool Count5/5
With 9 tools, this server is well-scoped for memory management, covering core operations like CRUD for memories and entities, plus search and listing. Each tool serves a clear purpose without redundancy or bloat.
Completeness5/5
The toolset provides complete coverage for memory management: create (add_memory), read (get_memory, get_memories, search_memories), update (update_memory), delete (delete_memory, delete_all_memories, delete_entities), and list (list_entities). No obvious gaps exist for the domain.
Average 3.7/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that removal is 'entire' and includes cascade-deletion of memories, which adds important context about destructive behavior. However, it doesn't cover other critical aspects like permissions needed, rate limits, error handling, or confirmation steps, leaving gaps in transparency for a high-impact deletion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads key information ('Remove a user/agent/app/run record entirely') and adds critical behavioral detail ('and cascade-delete its memories') without any wasted words. It's appropriately sized for the tool's complexity and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive tool with no annotations and an output schema exists (which handles return values), the description is moderately complete. It covers the core action and cascade effect but lacks important context like safety warnings, permission requirements, or error scenarios. For a high-stakes deletion tool, more completeness would be beneficial to guide safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter documented in the schema (e.g., 'Delete this user and its memories.'). The description adds no additional parameter semantics beyond what's in the schema, such as explaining parameter interactions or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description could have enhanced understanding of how multiple parameters work together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the resources affected ('user/agent/app/run record entirely'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling deletion tools like 'delete_memory' or 'delete_all_memories', which handle memory-specific deletions rather than entity-level deletions with cascading effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'delete_memory' or 'delete_all_memories'. It mentions cascade-deletion of memories, which hints at broader scope, but lacks explicit when-to-use rules, prerequisites, or warnings about irreversible deletion, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Overwrite' which implies a destructive mutation, but doesn't specify permissions needed, whether the operation is reversible, rate limits, error conditions (e.g., if memory_id doesn't exist), or what the output contains. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It is front-loaded and every word earns its place, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), 100% schema description coverage, and no complex nested objects, the description is minimally adequate. However, as a mutation tool with no annotations, it lacks critical behavioral context like safety warnings or error handling, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters (memory_id as 'Exact memory_id to overwrite' and text as 'Replacement text for the memory'). The description adds no additional parameter semantics beyond what the schema provides, such as format details or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Overwrite') and resource ('an existing memory's text'), distinguishing it from siblings like add_memory (create), delete_memory (remove), get_memory (read), and search_memories (query). It precisely communicates a mutation operation on a specific memory's content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that the memory must exist), exclusions (e.g., not for creating new memories), or comparisons to siblings like add_memory for creation or get_memory for reading. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action of fetching a memory and doesn't cover important aspects like error handling (e.g., what happens if the memory_id doesn't exist), authentication needs, rate limits, or whether it's a read-only operation. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose and key prerequisite. It is front-loaded with essential information and contains no unnecessary words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (which handles return values), a simple parameter set with full schema coverage, and no annotations, the description adequately covers the basic purpose and usage. However, it lacks details on behavioral aspects like error cases or permissions, which are important for a tool that fetches data, slightly reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'memory_id' clearly documented as 'Exact memory_id to fetch.' The description adds minimal value by reiterating the need for a memory_id but doesn't provide additional context like format examples or constraints beyond what the schema already states, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and resource ('a single memory'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'get_memories' or 'search_memories' beyond mentioning the need for a specific memory_id, which is already implied by the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some guidance by stating 'once you know its memory_id,' which implies this tool should be used when you have a specific identifier. However, it doesn't explicitly compare it to alternatives like 'get_memories' for listing multiple memories or 'search_memories' for finding memories without an ID, leaving usage context partially implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the destructive behavior ('Delete every memory') and clarifies that entities are preserved, but lacks critical details like whether this is irreversible, requires specific permissions, has rate limits, or returns confirmation data. For a mass-deletion tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Delete every memory'), specifies the scope, and adds a crucial qualifier ('but keep the entity'). Every word earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (mass deletion with 4 parameters) and lack of annotations, the description is incomplete despite having an output schema. It covers the basic purpose and scope but misses behavioral risks, permission requirements, and confirmation details that are critical for safe invocation. The output schema may help, but the description itself doesn't adequately prepare the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter well-documented in the schema. The description adds minimal value beyond the schema by implying these parameters define the deletion scope, but doesn't provide additional semantics like interaction effects between parameters or default behavior specifics. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete every memory') and resource ('in the given user/agent/app/run'), with explicit differentiation from siblings like delete_memory (singular) and delete_entities (different resource). The qualifier 'but keep the entity' further distinguishes it from delete_entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying scope parameters (user/agent/app/run) but doesn't explicitly state when to use this tool versus alternatives like delete_memory (for single deletions) or delete_entities (for deleting entities, not memories). No explicit exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the deletion action and user confirmation, but lacks details on permissions required, whether the deletion is permanent or reversible, error handling, or rate limits. For a destructive operation, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action ('Delete one memory') and includes essential context ('after the user confirms its memory_id'). There is no wasted verbiage, making it appropriately sized and structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a destructive operation with one parameter) and the presence of an output schema (which handles return values), the description is moderately complete. It covers the purpose and usage context but lacks behavioral details like safety warnings or error scenarios, which are important for a deletion tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'memory_id' documented as 'Exact memory_id to delete.' The description adds minimal value by restating this parameter in context ('its memory_id'), but does not provide additional semantics beyond what the schema already covers, aligning with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete one memory') and the resource ('memory'), distinguishing it from siblings like 'delete_all_memories' (which deletes multiple) and 'delete_entities' (which targets different resources). It precisely conveys the tool's function without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by specifying 'after the user confirms its memory_id,' indicating a prerequisite of user confirmation. However, it does not explicitly state when to use this tool versus alternatives like 'delete_all_memories' or 'update_memory,' missing explicit sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's a search operation (implies read-only), automatically injects 'user_id' into filters if not provided, and includes examples of filter logic. However, it doesn't cover aspects like rate limits, authentication needs, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by practical examples and an important note. Every sentence earns its place by providing actionable guidance without redundancy, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, semantic search functionality) and no annotations, the description does a good job covering usage and filter logic. With an output schema present, it doesn't need to explain return values. However, it could benefit from more explicit guidance on when to use this tool versus siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining filter usage with concrete examples and noting that 'user_id is automatically added to filters if not provided,' which clarifies parameter behavior beyond the schema's generic descriptions. It doesn't detail 'enable_graph' or 'limit' parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run a semantic search over existing memories.' It specifies the verb ('search') and resource ('memories'), but doesn't explicitly differentiate from sibling tools like 'get_memories' or 'get_memory' which might retrieve memories without semantic search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through examples of filter patterns, suggesting when to use this tool (for filtered semantic searches). However, it doesn't explicitly state when to choose this over alternatives like 'get_memories' or 'list_entities', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait: the requirement for at least one identifier (user_id, agent_id, or run_id). However, it lacks details on other important behaviors such as whether this is a write operation (implied by 'Store'), potential side effects, error conditions, or rate limits. The description adds some value but is incomplete for behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just two sentences—with zero wasted words. It is front-loaded with the core purpose and immediately follows with a critical requirement. Every sentence earns its place by providing essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, 1 required) and the presence of an output schema (which reduces the need to describe return values), the description is reasonably complete. It covers the purpose and a key requirement, but lacks details on behavioral aspects like mutation effects or error handling. With no annotations, it could be more comprehensive, but it meets basic needs for a storage tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are documented in the schema. The description does not add any parameter-specific information beyond what the schema provides (e.g., it mentions the identifier requirement but doesn't explain parameter interactions or semantics). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate with additional insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Store') and resource ('new preference, fact, or conversation snippet'), specifying what type of content can be stored. It distinguishes this tool from siblings like delete_memory, get_memories, and update_memory by focusing on creation rather than retrieval, modification, or deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to store new memory content. It explicitly states a prerequisite ('Requires at least one: user_id, agent_id, or run_id'), which helps guide usage. However, it does not explicitly mention when not to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's read-only nature (implied by 'List') and scope ('currently hold memories'), but lacks details on permissions, rate limits, or output format, leaving behavioral gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List which users/agents/apps/runs currently hold memories') with no wasted words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no annotations) and the presence of an output schema, the description is reasonably complete. It clearly states the tool's purpose and scope, though it could benefit from more behavioral context, which is partially mitigated by the output schema handling return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose without redundant parameter details, earning a baseline score for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List') and the target resource ('which users/agents/apps/runs currently hold memories'), distinguishing it from sibling tools like get_memories or search_memories that focus on memory content rather than entity holders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'currently hold memories,' suggesting it's for identifying active memory holders, but lacks explicit guidance on when to use this versus alternatives like get_memories or delete_entities, which target different operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: pagination mechanics (page and page_size), automatic user_id injection into filters, and the default page_size of 10. It also mentions the 'enable_graph' parameter's specific use case. However, it doesn't cover potential rate limits, error conditions, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficiently written. It starts with the core purpose, immediately provides usage guidance with examples, and ends with important behavioral notes. Every sentence serves a clear purpose—there's no redundant or filler content. The bullet-point examples are appropriately formatted for readability without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, filter logic), no annotations, but with 100% schema coverage and an output schema present, the description is quite complete. It covers the tool's purpose, usage patterns, key parameters, and important behaviors like automatic user_id injection and pagination. The output schema handles return values, so the description appropriately focuses on input semantics and usage context. Minor gaps include lack of error handling or performance characteristics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds significant value beyond the schema by providing concrete filter pattern examples (e.g., single user, agent memories, recent memories, multiple users) that illustrate the structure and logic of the 'filters' parameter. It also explains the automatic user_id injection behavior and gives context for 'enable_graph'. However, it doesn't elaborate on 'page' and 'page_size' beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Page through memories using filters instead of search.' It specifies the verb ('page through') and resource ('memories'), and distinguishes it from 'search_memories' by emphasizing the filter-based approach. However, it doesn't explicitly contrast with other siblings like 'get_memory' (singular) or 'list_entities'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Use filters to list specific memories' and contrasts it with search by stating 'instead of search.' It includes practical examples of filter patterns, which implicitly guide usage. However, it doesn't explicitly mention when NOT to use it or name specific alternative tools beyond the general 'search' reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mem0-mcp MCP server](https://glama.ai/mcp/servers/mem0ai/mem0-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mem0ai/mem0-mcp)

Score Badge

Copy to your README.md:

[![mem0-mcp MCP server](https://glama.ai/mcp/servers/mem0ai/mem0-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mem0ai/mem0-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mem0ai/mem0-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server