mcp-automem

Server Quality Checklist

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

Latest release: v0.14.1
Disambiguation5/5
Each tool has a clearly distinct purpose: store, recall, update, delete, associate, and health check. No overlap or ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., store_memory, delete_memory). Predictable and clear.
Tool Count5/5
Six tools is well-scoped for a memory management server, covering CRUD, graph association, and health monitoring without excess.
Completeness5/5
Covers all lifecycle operations (create, read, update, delete), plus association and health check. No obvious gaps for the domain.
Average 4.6/5 across 6 of 6 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 6 of 9 community issues answered or closed in the last 6 months
- 37 commits in the last 12 weeks
- Last stable release on June 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
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?
Annotations indicate idempotentHint=true and destructiveHint=false, which the description does not contradict. The description adds context about 'correct or enhance' but does not detail update semantics like overwriting vs merging (e.g., metadata merges per schema). Since annotations cover the core behavioral traits, the description provides moderate added value.
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 well-structured with a clear header, a bulleted 'When to use' list, and examples. It is concise (5 sentences plus examples) and front-loaded. Slightly more could be trimmed but overall efficient.
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 12 parameters (all documented in schema), an output schema exists, and annotations are present, the description provides sufficient context for the main purpose and use cases. It lacks error behavior details but these are not critical given the schema coverage.
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%, so the baseline is 3. The description does not add additional meaning beyond the schema; it only groups parameters in the first sentence. Examples illustrate some parameters but no new semantics.
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 'Update' and the resource 'memory', and lists the updateable fields (content, tags, importance, metadata). It distinguishes from the sibling tool 'store_memory' by advising against storing duplicates.
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 'When to use' section provides four explicit use cases (correct inaccuracies, add tags, adjust importance, add metadata) and implicitly advises against using store_memory for updates. However, it does not mention when not to use this tool (e.g., if memory should be deleted entirely) or prerequisites (e.g., memory must exist).
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?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint false. Description adds value by specifying the components checked (FalkorDB graph + Qdrant vectors) and the service context (AutoMem). No contradictions.
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?
Extremely concise: one-line purpose, bulleted use cases, and example. Every sentence adds value. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema, the description is complete. It covers purpose, usage guidance, and provides an example. No gaps.
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?
No parameters (0 params, baseline 4). Schema coverage is 100%, so description does not need to compensate. The description effectively explains the tool's purpose without needing parameter details.
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 verb+resource: 'check the health status of the AutoMem service and its connected databases'. Differentiates from sibling tools like store_memory and recall_memory which are CRUD operations.
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?
Provides explicit when-to-use scenarios: before a session, when memory operations fail, and to check statistics. Does not mention when not to use or alternatives, but sibling differentiation makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, idempotentHint=true, destructiveHint=false, which describe the tool as non-destructive and idempotent. The description adds that batch mode supports up to 500 associations, lists valid authorable relationship types, and notes that internal relation types appear in recall but are not valid inputs. This provides rich behavioral context beyond annotations.
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: overview, when-to-use, relationship types list, examples. It uses bullet points for readability and avoids unnecessary repetition. Every sentence serves a purpose, and the length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, batch mode, many relationship types), the description covers all key aspects: purpose, usage scenarios, relationship type explanations, batch mode limits, and examples. The presence of an output schema means return values don't need to be described. The description is fully adequate for an agent to select and invoke the tool correctly.
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% (all parameters have descriptions in the schema). The description adds value by explaining which parameters are relation-specific (e.g., reason for PREFERS_OVER, confidence for EXEMPLIFIES) and by listing relationship types with meanings. The examples also illustrate parameter usage. Overall, the description enhances understanding beyond the schema descriptions.
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 'creates typed relationships between memories' and explains it improves recall via a knowledge graph. This distinguishes it from sibling tools like store_memory (store a single memory) and recall_memory (retrieve memories).
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 includes a 'When to use' section with specific scenarios (e.g., after storing a new memory, when a bug fix relates to a feature). It also distinguishes between single-pair and batch mode, and clarifies which relationship types are not valid inputs. However, it does not explicitly state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses supersede behavior (marks old invalid, merges metadata, creates relation), content size limits, batch mode restrictions, and mode-specific parameter constraints. Adds significant value beyond minimal annotations.
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?
Well-structured with sections for modes, guidelines, when to use, and examples. Slightly verbose but not wasteful. Could be tightened by removing some redundant parameter descriptions already in schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all modes, parameter constraints, and use cases. With 17 parameters and nested objects, the description is thorough. Output schema exists so return values are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds crucial context: content size guidelines (150-300 chars targeting), importance values (0.9+ critical), and supersede parameter explanations. Provides examples that clarify usage.
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 memory' and distinguishes between single and batch modes. It differentiates from siblings (associate, delete, recall, update) by being the creation tool.
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?
Provides explicit 'When to use' scenarios (decisions, patterns, bugs, preferences, bulk ingestion). However, it doesn't explicitly state when to use alternatives like recall_memory or update_memory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, not destructive. The description adds substantial behavioral context beyond annotations: mode-specific routing (GET /memory/{id}, GET /memory/by-tag), parameter interactions (memory_id ignores others), pagination metadata, tag matching rejection policy in enumeration mode, and server-side clamping limits. This fully informs the agent of behaviors.
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 lengthy but well-structured with clear headings, bullet points, and labeled examples. Every sentence adds value; no filler. The three-mode structure is front-loaded, and examples are concise. Given the tool's complexity (38 parameters), this level of detail is warranted and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 38 parameters, zero required, full schema coverage, and an output schema, the description is remarkably complete. It covers all three modes, edge cases (parameter rejection, server clamping), pagination, and provides 5 diverse examples. No missing information is apparent for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant semantic value: it groups parameters by mode, explains constraints (e.g., enumeration mode rejects tag_match='prefix' and tag_mode='all'), provides examples combining parameters, and clarifies server-side behaviors (e.g., rank limit clamped to ~50). This goes beyond the schema's individual descriptions.
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 it recalls memories from AutoMem in three distinct modes, with specific verbs ('recall', 'fetch', 'enumerate') and resource ('memories'). It distinguishes itself from sibling tools by being read-only, contrasting with store/delete/update. The three-mode structure provides precise intent.
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 gives explicit when-to-use guidance for each mode: ranked for context and decisions, enumeration for cleanup/audit, ID fetch for single retrieval. It provides scenario examples. However, it does not explicitly state when not to use this tool versus alternatives (e.g., store_memory for recording), so it slightly misses the mark for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures beyond annotations: idempotent for single mode, not idempotent for bulk, exact case-insensitive tag matching, no dry-run, potential for mass deletion. No contradiction with annotations indicating destructive and non-idempotent 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?
Well-structured with headings, bullet points, and examples. Information is presented efficiently and front-loaded with core action, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and parameters fully described, the description covers all essential aspects: modes, usage context, safety warnings, and verification steps. No important gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds XOR relationship, mode differentiation, exact tag matching details, and no-dry-run warning. This significantly enhances understanding beyond schema descriptions.
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 deletes memories by ID or bulk by tag, specifying two modes with distinct behaviors. It differentiates from sibling tools like update_memory, providing a precise action and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use sparingly and consider update_memory instead, and provides specific scenarios for each mode, including verification steps for bulk deletion. This gives clear when-to-use and when-not-to-use guidance.
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:

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

Score Badge

Copy to your README.md:

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

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/verygoodplugins/mcp-automem'

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