mem0-mcp-selfhosted

Server Quality Checklist

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

Latest release: v0.3.2
Disambiguation4/5
Most tools have distinct purposes: add, get, update, delete, search, and entity management. However, delete_all_memories and delete_entities could be confused as both are bulk deletions, and get_memories vs search_memories may cause ambiguity despite different filtering/semantic approaches.
Naming Consistency4/5
The majority follow a consistent verb_noun pattern (e.g., add_memory, delete_memory). Two tools (mcp_get_entity, mcp_search_graph) deviate with an 'mcp_' prefix, breaking the otherwise uniform style.
Tool Count5/5
With 11 tools, the server covers core memory CRUD, search, and entity operations without being excessive. This count is well-scoped for a focused memory management MCP server.
Completeness5/5
The tool surface includes creation, retrieval (by ID, pagination, semantic search), update, and multiple deletion methods, plus entity listing and graph search. This provides comprehensive lifecycle coverage for agent memory management.
Average 3.6/5 across 11 of 11 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 3 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action without mentioning destructive nature, permissions needed, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified for a tool with no annotations. It could include more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not mention return values or behavior on failure. For a destructive operation, more context is needed.
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 coverage is 100% and describes the parameter as 'Exact memory UUID to delete.' The description adds no additional meaning beyond the schema.
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 'Delete a single memory' clearly states the action (delete), resource (memory), and scope (single), distinguishing it from siblings like delete_all_memories and get_memory.
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?
No guidance on when to use this tool versus alternatives like delete_all_memories, nor any prerequisites or disclaimers.
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 present, so the description must disclose behavior. It only says 'semantic search' without stating that it is read-only, what the output format is (though output schema exists), or any side effects. Minimal behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of only two words plus context. While it could be more informative without becoming verbose, it avoids unnecessary fluff and is clearly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no annotations, the description is insufficient. It does not explain how filtering works, the role of threshold/rerank, or how this tool relates to sibling tools like get_memories or mcp_search_graph. The output schema partially compensates, but the description lacks essential context.
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?
All 9 parameters have descriptions in the input schema (100% coverage), so the description adds no extra information beyond the schema. The baseline of 3 is appropriate as the schema already documents parameters adequately.
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 it performs semantic search across memories, distinguishing it from add/get operations. However, it does not explicitly differentiate from other retrieval tools like get_memories, though 'semantic' hints at the difference.
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?
No guidance on when to use semantic search versus other retrieval methods (e.g., get_memories) or alternative tools like list_entities. The description lacks any context for appropriate usage.
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 must disclose behavioral traits. It mentions using a safe bulk-delete instead of memory.delete_all(), but this is vague. It fails to describe error handling, reversibility, or permission requirements, leaving significant gaps 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence front-loads the core purpose. The second sentence includes an implementation detail ('NEVER calls memory.delete_all()...') that is somewhat extraneous and could be confusing, slightly reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 optional parameters requiring at least one filter) and the presence of an output schema, the description does not explain what happens when no filter is provided or what the return value indicates (e.g., number of deleted memories). It is incomplete for an agent to confidently invoke the 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?
The input schema has 100% coverage, so the descriptions of user_id, agent_id, and run_id are already clear as scope filters. The description adds the constraint that at least one filter must be provided, which adds meaning beyond the schema's default-null indicators. However, it doesn't elaborate on parameter usage beyond this.
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 tool bulk-deletes all memories within a given scope, using specific verbs and resources. It distinguishes itself from sibling 'delete_memory' by implying a bulk operation, and the requirement of at least one filter aligns with the input schema parameters.
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 a usage condition: 'Requires at least one filter.' This implies when to use the tool but does not explicitly compare it to alternatives like 'delete_memory' or provide when-not scenarios. The note about using safe bulk-delete gives behavioral context but not usage boundaries.
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 must disclose behavioral traits. It mentions pagination and filtering but lacks details on read-only nature, authentication needs, rate limits, pagination mechanics (e.g., cursor, offset), or behavior when no memories match. The contrast with 'search' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded and free of unnecessary words. It is appropriately short for a simple tool, though it could benefit from a bit more detail without becoming 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 presence of an output schema (not shown), the description need not explain return values. The tool is straightforward, with 0 required parameters and clear schema. However, pagination behavior (e.g., default limit, ordering) is not addressed, 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, so each parameter (user_id, agent_id, run_id, limit) is already documented in the schema. The description adds no further meaning beyond what the schema provides, earning a baseline score of 3.
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 tool's purpose: 'Page through memories using filters instead of search.' It uses a specific verb ('page through'), identifies the resource ('memories'), and explicitly contrasts with 'search' (sibling tool search_memories), distinguishing it effectively.
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 for paginated filtering rather than search, but does not explicitly state when to use this tool vs. alternatives like search_memories. No clear prerequisites or exclusions are provided, leaving room for ambiguity.
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 of behavioral disclosure. It indicates a read-only operation (fetches relationships) and mentions bidirectionality, which is helpful. However, it does not clarify side effects (likely none), error cases (e.g., entity not found), or performance characteristics. The description is adequate but minimal.
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 at one sentence (9 words), front-loading the core functionality. Every word is necessary, and there is no redundancy or unnecessary information.
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 existence of an output schema (which presumably defines the response structure), the description does not need to explain return values. It covers the basic purpose and scope (all relationships, bidirectional). However, it could optionally mention what happens if the entity has no relationships or is not found. Still, it is largely complete for a simple lookup 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?
The input schema provides full description coverage (100%) for the single parameter 'name' with clear documentation ('Exact entity name to look up'). The description adds only the 'bidirectional' scope but does not enhance parameter understanding beyond the schema. Baseline 3 is appropriate.
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 tool retrieves all relationships for a specific entity, with bidirectional semantics. It uses a specific verb ('Get') and resource ('relationships for a specific entity'), and distinguishes from sibling tools like list_entities (which lists entities, not relationships) and mcp_search_graph (which is for graph-wide searches).
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 does not provide explicit guidance on when to use this tool versus alternatives. It lacks context about prerequisites, limitations, or when not to use it. Sibling tools like search_memories or mcp_search_graph might also retrieve relationship information, but no comparison is offered.
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, the description carries full burden but only states 'Store a new memory.' It omits behavioral traits such as whether this is a write operation, side effects, or authorization needs. The constraint on scope IDs is noted but insufficient for full 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 two sentences, front-loaded with the core purpose. Every word adds value, and there is no unnecessary repetition.
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 (8 parameters, output schema exists), the description is adequate but incomplete. It does not clarify behavior for parameters like 'infer' or 'enable_graph,' though these are documented in the schema. Output schema mitigates need for return value explanation, but the description could provide more behavioral context.
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 coverage is 100%, so baseline is 3. The description adds value by stating that at least one of user_id, agent_id, or run_id is required—a cross-parameter constraint not explicit in the schema alone. This justifies a score above baseline.
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 'Store a new memory,' which is a specific verb+resource. It distinguishes this from sibling tools like delete_memory or get_memories, which have different purposes.
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 includes a requirement ('at least one of user_id, agent_id, or run_id'), which provides context for valid invocations. However, it does not offer guidance on when to use this tool versus alternatives like search_memories or update_memory.
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 full burden. 'Fetch' implies a read-only operation but does not disclose error handling (e.g., behavior when memory_id not found). For a simple retrieval, this is minimally adequate.
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, concise sentence with no superfluous words. It is front-loaded and immediately understandable.
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 has one parameter and an output schema (assumed from context signal), the description covers the essential purpose. It lacks explicit mention of error cases or return format, but these are partially addressed by the output schema. Completeness is high for such a simple 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?
The input schema already provides a clear description for memory_id ('Exact memory UUID to fetch'). The tool description adds no additional parameter information beyond the schema. With 100% schema coverage, score is at baseline 3.
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 'Fetch a single memory by its ID' clearly states the verb ('Fetch'), resource ('memory'), and scope ('single by ID'). It naturally distinguishes from sibling tools like get_memories (plural) and add_memory.
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 does not provide explicit guidance on when to use this tool versus alternatives (e.g., get_memories for listing, search_memories for queries). The usage is implied by the purpose, but no direct comparison or exclusions are stated.
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 burden of disclosing behavioral traits. It clearly states the cascade-delete behavior, which is a key destructive aspect. However, it does not mention irreversibility, required permissions, or potential side effects, which would further enhance 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 with two sentences, front-loading the main purpose. Every word is functional, and there is no unnecessary information. It efficiently communicates the core functionality.
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 destructive nature and zero annotations, the description could be more complete. It does not mention return values (though output schema exists) or warn about permanent data loss. It flags the equivalence to delete_all_memories but lacks broader context like error handling or constraints.
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 coverage is 100% with each parameter having a description. The description adds minimal additional meaning beyond what the schema already provides, such as the cascade effect for user_id already noted in the schema. Thus, it meets the baseline of 3 without significant enhancement.
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 tool's purpose: deleting an entity and cascade-deleting all its memories. It also distinguishes itself by noting functional equivalence to delete_all_memories in self-hosted mode, which helps differentiate from sibling tools like delete_all_memories.
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 minimal guidance on when to use this tool. It only mentions functional equivalence to delete_all_memories in self-hosted mode, implying a context-dependent preference, but does not explicitly state when to use this tool versus alternatives or provide prerequisites.
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?
Description discloses substring matching behavior, which is helpful. But no annotations exist, so description should also cover case sensitivity, pagination, limits, or what exactly 'name/id' means. It's somewhat transparent but lacks depth.
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?
Single sentence with no wasted words. Front-loaded with action. Perfectly concise for a simple tool.
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 output schema likely describes return format, the description covers the search mechanism. Missing details like case sensitivity or pagination would improve completeness, but not critical for a simple 1-param tool.
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 provides basic description for 'query' param. Description adds context about substring matching on name/id, which goes beyond schema's generic 'Entity or topic to search for'. High schema coverage (100%) but description still adds value.
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?
Description clearly states the tool searches entities by substring matching on name/id, which is specific and distinguishes from siblings like list_entities or mcp_get_entity.
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?
Description implies usage for substring searches but does not explicitly state when to use vs alternatives like list_entities (all entities) or mcp_get_entity (exact match). No exclusions provided.
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, the description provides valuable behavioral context: it re-embeds and re-indexes, which is a side effect beyond the basic operation. This aids an agent in understanding consequences, though it could be more comprehensive about error states or idempotency.
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?
Two sentences, front-loaded with the main action. Every word adds value: 'Overwrite' is specific, and the side effects are succinctly stated. No 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 simplicity and 100% schema coverage, the description is largely complete. It covers the operation and a key side effect. Missing details like return format or prerequisite that memory exists, but output schema exists (though not provided) and context is nearly sufficient.
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 coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; it mentions 'text' but not 'memory_id'. The parameter types are self-explanatory from the schema.
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 tool overwrites an existing memory's text, using a specific verb ('overwrite') and resource ('memory's text'). It distinguishes from siblings like add_memory (creation) and delete_memory (removal) by focusing on update.
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 for updating an existing memory's text, but does not explicitly state when to use it versus alternatives (e.g., when to add vs update), nor does it provide exclusions or prerequisites.
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?
Discloses internal behavior (Qdrant Facet API with fallback) and implies read-only nature. Since no annotations exist, this adds valuable context beyond what structured fields provide.
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?
Two sentences, each earning its place: first states purpose, second adds technical transparency. No wasted words.
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?
Covers purpose and internal behavior succinctly. With an output schema present, return values need not be described. Slightly lacking on when to use 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?
Zero parameters with 100% schema description coverage (trivially). Description adds no parameter details but is unnecessary due to lack of parameters.
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 'List' and the resource 'which users/agents/runs currently hold memories'. It distinguishes from sibling tools like get_memories and search_memories by focusing on entities that hold memories.
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?
Provides version-specific implementation details but no explicit guidance on when to use this tool versus alternatives like search_memories or mcp_get_entity. Usage context is implied but not stated.
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-selfhosted MCP server](https://glama.ai/mcp/servers/elvismdev/mem0-mcp-selfhosted/badges/card.svg)](https://glama.ai/mcp/servers/elvismdev/mem0-mcp-selfhosted)

Score Badge

Copy to your README.md:

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

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/elvismdev/mem0-mcp-selfhosted'

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