Memento

by JoyciAkira

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.2.1
Disambiguation2/5
Many tools serve overlapping memory/context purposes (e.g., memento, memento_remember, memento_search, memento_cognitive) and knowledge graph operations (memento_graph, memento_kg), making it hard for an agent to select the correct tool.
Naming Consistency4/5
Most tools follow the 'memento_' prefix pattern, but the first tool is simply 'memento' without the prefix, breaking consistency. Otherwise, naming is uniform.
Tool Count5/5
With 14 tools covering memory, configuration, health, graph, sessions, and more, the count is well-scoped for the server's comprehensive purpose.
Completeness4/5
The tool surface covers a wide range of operations (add, retrieve, search, configure, diagnose, etc.), but lacks explicit delete/forget actions for memories, which is a minor gap.
Average 2.5/5 across 14 of 14 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- Last stable release on July 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under AGPL 3.0.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses no behavioral traits such as side effects (e.g., destructive nature of remove_rule), authorization requirements, or state modifications beyond action names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but fails to provide necessary details. It is under-specification rather than conciseness, lacking any meaningful structure or prioritization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, nested objects, no output schema), the description is completely inadequate. It provides no information about return values, input constraints, or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any meaning to parameters like preset, rule_id, rule, workspace_root. The agent is left with no clue about their purpose or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Active Coercion management' which is vague and unclear in context. It lists actions but does not specify what coercion means or how it differs from sibling tools like memento_configure or memento_cognitive.
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. The description only lists action names without any context on preferred use cases or when to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides no behavioral details such as side effects, permissions required, or destructive potential. For a configuration tool, this is a critical omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but at the cost of clarity. It front-loads the verb 'Configure' but the rest is a bare list of actions. This is under-specification, not conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, many enums, no output schema, no annotations), the description is severely incomplete. It fails to explain what the tool does for each action or how parameters interact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage and 9 parameters, the description only lists action enum values without explaining their meaning or the purpose of other parameters like 'level', 'state', or 'warnings'. It adds virtually no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Configure Memento' and lists actions, giving a general sense of purpose. However, it lacks specifics on what each action configures, making it vague and not fully clear for distinguishing among sibling tools.
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 is provided on when to use this tool versus alternatives like memento_coercion or memento_cognitive. The absence of usage context or when-not-to-use conditions hurts decision-making.
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 states 'copy-only migration' indicating non-destructive behavior, but fails to explain side effects, idempotency, error handling, or safety considerations like whether the source DB is modified or if the tool can be re-run safely.
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 a single sentence and a result note. It front-loads the key action and output, avoiding unnecessary verbosity. However, it could benefit from structured sections for clarity.
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?
For a migration tool with no output schema and limited schema descriptions, the description omits important context such as the format of the JSON report, expected behavior under failure, required permissions, and the exact nature of the 'deterministic text heuristics'. This leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 25% of schema parameters have descriptions (workspace_root has a description but contradictory 'MANDATORY' vs not required in schema). The tool description does not compensate for the missing parameter explanations for source_db_path, workspace_roots, and report_path, leaving agents uncertain about input requirements.
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 is a 'copy-only migration' tool that redistributes memories from a source DB into per-workspace DBs using deterministic text heuristics, which distinguishes it from other memento tools that handle queries or configurations. However, it could explicitly contrast with sibling tools like memento_remember or memento_search.
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 implies usage when migration is needed, but lacks conditions, prerequisites, or when not to use it. No mention of alternatives among siblings.
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 does not state whether the tool is read-only, modifies dependencies, or requires network access. The word 'audit' implies inspection, but this is implicit.
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, well-front-loaded sentence that defines the tool's purpose and key terminology. No wasted words.
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?
The tool has no output schema and no annotations, so the description should compensate with more context (e.g., return format, side effects, permissions). It falls short given the complexity of dependency auditing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. However, the description calls workspace_root 'MANDATORY' while the schema lists it as optional (no 'required' array), creating confusion. This inconsistency reduces clarity.
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 audits workspace dependencies and defines the two categories (orphans and ghosts). It distinguishes itself from siblings by focusing on dependency auditing, but does not explicitly differentiate from similar tools like memento_project or memento_graph.
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 vs alternatives (e.g., memento_health, memento_search). No mention of prerequisites or typical use cases.
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 bears full responsibility for behavioral transparency. It states actions and their intents (e.g., 'align (goal check)') but fails to explain side effects, state changes, or limitations. For example, 'warnings (spider-sense)' is ambiguous—does it check something? Does it modify state? The description lacks details on error conditions, idempotency, or required setup.
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 very concise—two lines, front-loaded with the core concept ('Cognitive engine') followed by a colon and a bullet-like list of actions. Each action gets a one-word hint. There is no extraneous text. While it could be slightly more structured (e.g., separate lines), it efficiently conveys the gist.
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 no annotations, no output schema, 5 parameters with low schema coverage, and four distinct actions, the description is incomplete. It does not explain return values, error handling, or use cases. For example, 'tasks (auto-generate)' is vague—what tasks? Based on what? The lack of any output description or further context makes the tool under-specified for an agent to use correctly.
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 40% (2 of 5 parameters have descriptions). The description adds meaning to the 'action' enum by associating each value with a one-word explanation (e.g., 'dream (creative insight)'), supplementing the schema's pure enum list. However, the parameters 'active_context' and 'workspace_root' are completely undocumented in both schema and description. The description does not compensate for the missing schema descriptions elsewhere.
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 states it's a 'cognitive engine' and lists four actions with brief explanations (dream, align, warnings, tasks). Each action has a one-word hint (e.g., 'creative insight'). This clearly communicates the tool's purpose and distinguishes it from sibling tools that have different names like memento_search or memento_remember. However, it doesn't explain how these actions relate to each other or what the tool outputs.
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 is given on when to use this tool versus its siblings (e.g., memento_search, memento_remember). There is no indication of prerequisites, context, or examples. The description only lists available actions without explaining the decision criteria for choosing one action over another or when this tool is preferred over alternatives.
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, and the description does not disclose whether the tool is read-only, has side effects, or any safety information. It only explains search modes without behavioral details like performance or resource consumption.
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 very concise, using a single sentence to state purpose and list modes. It is front-loaded with the key verb and resource, but could be more structured and informative without adding verbosity.
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 complexity of 7 parameters (including nested objects) and no output schema, the description is insufficient. It does not cover return format, filter behavior, or the role of trace and active_context, leaving the agent with incomplete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 14% (query has description). The description adds meaning for the mode parameter by explaining the modes, but the other 6 parameters (limit, filters, trace, active_context, workspace_root) lack any additional description, leaving a significant gap.
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 'Search memories' as the primary function and distinguishes three modes (basic, advanced, explain), differentiating it from sibling tools like memento_remember (for creating memories) and memento_audit_dependencies.
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 lists modes but does not provide explicit guidance on when to use this tool versus alternatives or when to choose each mode. Usage is implied by the name and hierarchy, but no exclusions or contextual cues are given.
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:

[![memento MCP server](https://glama.ai/mcp/servers/JoyciAkira/memento/badges/card.svg)](https://glama.ai/mcp/servers/JoyciAkira/memento)

Score Badge

Copy to your README.md:

[![memento MCP server](https://glama.ai/mcp/servers/JoyciAkira/memento/badges/score.svg)](https://glama.ai/mcp/servers/JoyciAkira/memento)

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/JoyciAkira/memento'

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