Mnemosyne MCP

by zhadyz

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.1.2
Disambiguation4/5
Most tools have clear distinct purposes, but search_nodes, semantic_search, and open_nodes all relate to finding nodes with subtle differences; similarly, read_graph, get_graph_at_time, and get_decayed_graph are distinct temporal/decay views but could be confused by an agent.
Naming Consistency4/5
The naming is largely consistent with verb_noun snake_case (e.g., create_entities, delete_relations, add_observations). Minor deviations include 'read_graph' vs 'get_graph_at_time' and 'search_nodes' vs 'semantic_search', which break the pattern slightly but remain readable.
Tool Count4/5
17 tools is slightly above the typical 3-15 sweet spot, but the knowledge graph domain with history, embeddings, and temporal views justifies the additional tools. It feels a bit heavy but not excessive.
Completeness3/5
The surface covers creation, deletion, and relation management well, but there are notable gaps: no update_entities or update_observations, and no explicit single-entity getter (open_nodes is name-based rather than ID-based). These gaps force agents to work around the incomplete CRUD lifecycle.
Average 3.4/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states the action and does not disclose irreversibility, required permissions, partial failure behavior, or return format. The description adds no behavioral insight beyond the basic operation.
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, front-loaded sentence with no superfluous words. It efficiently communicates the core function without redundancy.
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?
This is a destructive mutation tool with no annotations and no output schema. The description fails to mention side effects, irreversibility, prerequisites, or the exact parameter structure. The description is too minimal to fully support confident invocation.
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?
The schema has one parameter 'deletions' with 0% top-level description coverage. The tool description hints at entities and observations, but it does not explain the array-of-objects structure or the required fields entityName and observations. The description provides minimal compensatory value for the schema 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 the action ('Delete') and the target ('specific observations from entities'), making it distinct from sibling tools like delete_entities and delete_relations. It precisely identifies the resource and operation.
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 such as add_observations or delete_entities. It lacks context about prerequisites, exclusions, or conditions where this tool is preferred.
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 full responsibility for behavioral disclosure. It implies a read-like operation ('open') but does not explicitly state that it is non-destructive, what happens if names are not found, or whether it returns full node structures. This is a significant gap for a tool with no annotation support.
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 that immediately conveys the action and target. It contains no fluff or redundant information, making it efficient and well-structured.
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 simple schema and no output schema, the description is minimally viable, but it lacks context about how this tool relates to siblings like read_graph or search_nodes. An agent may not know whether to use open_nodes for a full-graph read or for retrieving specific entities, leaving ambiguity in a larger tool ecosystem.
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 schema covers the only parameter 'names' fully with a description ('An array of entity names to retrieve'), and the tool description reiterates this by saying 'by their names.' With 100% schema coverage, the baseline is 3, and the description adds no additional meaning beyond what the schema already provides.
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: 'Open specific nodes' in the knowledge graph by name. The verb 'open' and resource 'nodes' are specific, and 'by their names' indicates a lookup operation. However, it does not explicitly distinguish from sibling tools like read_graph or search_nodes, so it misses full sibling differentiation.
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 any prerequisites, exclusions, or context such as 'use search_nodes when you don't know exact names.' This leaves the agent without clear direction on tool selection.
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 only states the action without disclosing behavior such as idempotency, validation, limits, or side effects. For a mutation tool, this is insufficient; an agent cannot anticipate what happens on failure or whether existing entities are affected.
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 one sentence, concise and front-loaded. It avoids unnecessary words. However, it is so brief that it omits essential information, making it too minimal for a complex tool.
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 a nested entity array with many optional fields, but the description offers no guidance on the input structure or return behavior. There is no output schema, so the description carries full responsibility for explaining the tool's behavior, which it fails to do.
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?
The description says nothing about the parameters; schema description coverage is 0%. While the schema itself contains detailed property descriptions, the tool description does not add any meaning beyond what is structured, failing to compensate for the low 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 action (create), the resource (multiple new entities), and the context (Memento MCP knowledge graph). This distinguishes it from sibling tools like create_relations or add_observations which target different resources.
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 usage is implied: use this when you need to add new entities. However, it provides no explicit guidance on when to choose this over alternatives, nor any prerequisites or exclusions. For a create operation, the intent is straightforward, but the lack of any alternative comparison leaves room for ambiguity.
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 only states the action without clarifying whether deletion is permanent, whether it is idempotent, or what response is returned. The word 'delete' implies mutation but lacks important safety and side-effect context.
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 that front-loads the action and resource with no redundant or unnecessary information. Every word earns its place.
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 description is minimal and lacks behavioral context for a destructive operation. It does not mention permanence, error handling, side effects, or return value expectations. With no output schema and no annotations, the description alone is insufficient for an agent to fully anticipate the operation's effects, especially given it is a delete action.
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 fully describes the single 'relations' parameter, including the nested fields from, to, and relationType, achieving 100% schema description coverage. The description adds no additional semantic meaning beyond what the schema already provides, so the baseline score of 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 verb 'Delete' and the resource 'multiple relations' within the Memento knowledge graph, making the tool's function immediately obvious. It also distinguishes itself from sibling tools like delete_entities, which targets entities, and delete_observations, which targets observations.
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. It does not mention scenarios where this tool is preferred over delete_entities or when to avoid it, leaving the agent to infer usage context.
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?
There are no annotations to declare safety or mutation, so the description carries full responsibility. It does not disclose what happens if the relation doesn't exist, whether the update is partial or full replacement, how versioning is handled, or if there are any validation constraints. The vague 'enhanced properties' adds no concrete behavioral detail.
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, grammatically correct sentence that is easy to parse. It is appropriately concise and front-loaded with the verb and object. It could be slightly more informative, but it contains no unnecessary 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?
Given the complexity of the nested 'relation' object with numerous optional fields, the lack of output schema, and no annotations, this description is too minimal. It fails to clarify critical update semantics such as which fields are required for identification, whether the operation is a partial merge or full replacement, and the meaning of 'enhanced properties'. The description alone is insufficient for an agent to invoke the tool correctly.
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?
The description provides no parameter-level detail. 'Enhanced properties' gives a hint that the nested 'relation' object contains updates, but it does not explain which fields identify the relation versus which ones are updated. With low schema_description_coverage (0%), the description fails to compensate, despite the schema having well-documented fields.
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 action ('Update') and the resource ('existing relation'), and specifies the context ('Memento MCP knowledge graph memory'). It distinguishes itself from sibling tools like create_relations and delete_relations by intentionally targeting existing relations, and the 'enhanced properties' hints at additional attribute updates.
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 word 'existing' implies the relation must already be present, suggesting this is not for creation, but there is no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like delete and recreate, nor any prerequisites for updating a relation.
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 the full burden for behavior disclosure. It only states that relations are created, but does not mention idempotency, overwrite semantics, validation of entity existence, transactional behavior, or what happens on partial failure. The mutation effect is implied but no further behavioral context is given.
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 with no redundancy. It front-loads the core action and purpose, then adds a concise stylistic guideline. Every word earns its place, making it highly efficient for an agent to parse quickly.
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?
This is a complex tool with a nested array of 13 fields, no annotations, and no output schema, yet the description offers only a high-level purpose. It lacks crucial context such as whether entities must already exist, how failures are handled, whether the operation is atomic, and what the tool returns. The sparse description is inadequate for an agent to use the tool safely and effectively.
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 description coverage is 0% for the top-level parameter, yet the description does not explain the array structure of 'relations' or the required fields. It adds the active voice requirement for relationType, which is helpful, but this only partially compensates. The nested schema descriptions exist but are not referenced or clarified by the tool description.
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 action (create multiple new relations) and the resource (between entities in the Memento MCP knowledge graph). It distinguishes from siblings like update_relation and delete_relations by focusing on creation, and the 'multiple' wording distinguishes it from any single-relation tool. The scope is unambiguous.
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 use for batch-creating relations ("multiple new relations"), but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or exclusions, though sibling tool names like update_relation suggest the contrast. The 'active voice' note is a formatting guideline, not a usage context.
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 carry the full burden of behavioral disclosure. It only says 'Get the version history', which implies a read operation but offers no details about return format, side effects, required permissions, or limitations. This is a significant gap for a tool without annotation support.
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 of 15 words, front-loaded with the action 'Get the version history'. It wastes no words and is easily scannable.
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?
The description captures the core purpose but omits details about the returned history structure or how it differs from entity history. With no output schema and no annotations, an agent may lack sufficient context to fully understand the tool's behavior, but the tool is a simple getter and the schema helps.
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 covers all three parameters (from, to, relationType) with descriptions, achieving 100% coverage. The description adds no additional parameter meaning, so the baseline of 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 'Get the version history of a relation' with a specific verb and resource, and explicitly mentions 'history' to distinguish from the sibling tool get_relation which likely returns the current state. It also provides context that this is from the Memento MCP knowledge graph 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?
There is no guidance on when to use this tool instead of get_relation, get_entity_history, or other siblings. No alternatives or exclusions are mentioned. The description merely defines the action without contextual usage hints.
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 does not state whether the search is read-only, what it returns, or any limitations (e.g., pagination, scope). It only says 'search for nodes' without clarifying behavior beyond that obvious action, leaving the agent without safety or side-effect information.
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, front-loaded sentence with no redundant words. It communicates the essential purpose efficiently, earning its place without any waste. This is an ideal level of conciseness for a simple tool.
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?
The tool has one parameter and no output schema, so complexity is low. However, the lack of annotations and absence of any usage guidance or behavioral context makes the description only minimally complete. It covers the basic purpose but omits important context like safety (read vs. write) and relationship to the sibling 'semantic_search' tool, leaving gaps for 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%, so the baseline is 3. The input schema already provides a clear description of the 'query' parameter ('match against entity names, types, and observation content'). The tool description adds no additional parameter semantics beyond what the schema already states, so it does not exceed the baseline.
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 function: 'Search for nodes in your Memento MCP knowledge graph memory based on a query.' It specifies a verb ('search'), a resource ('nodes'), and a mechanism ('based on a query'). However, it does not distinguish itself from the sibling tool 'semantic_search', which likely performs a similar function, so it misses the opportunity to differentiate.
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 query-based search of nodes, but it does not provide explicit guidance on when to use this tool versus alternatives like 'semantic_search' or 'open_nodes'. There are no stated exclusions or alternative tool references, so the guidance is only implied, not explicit.
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 the full burden, but it only restates the core action. It does not disclose behavior around non-existent entities, overwriting, errors, or side effects, leaving significant gaps for a mutation 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, front-loaded sentence with no filler or redundant content. It communicates the essential purpose efficiently.
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 a moderately rich schema, the tool has no annotations or output schema, and the description is too terse. It omits behavioral context (e.g., what happens if an entity doesn't exist, whether defaults apply) and return semantics, making it incomplete for a nested mutation 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 75%, and the schema already documents parameters like entityName, contents, metadata, strength, and confidence. The description adds no extra parameter-level nuance, but the schema provides enough meaning to warrant a 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 uses a specific verb ('Add') and resource ('observations to existing entities'), clearly distinguishing it from sibling tools like create_entities or delete_observations. It also scopes the operation to existing entities, which is helpful.
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 phrase 'to existing entities' implies this is for attaching observations to already-created entities, but it does not explicitly mention alternatives or when not to use it. No exclusions or alternative tool names are given.
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 disclosing behavioral traits. It only says 'get,' which implies a read-only operation, but it doesn't explicitly confirm safety, side effects, or prerequisites. The vague phrase 'enhanced properties' doesn't clarify behavior, leaving the agent to infer from the name alone.
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 that communicates the tool's purpose without unnecessary words. It is front-loaded with the key action and resource, and every word earns its place.
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?
Since there is no output schema, the description should explain what is returned, especially the vague 'enhanced properties.' It doesn't specify the response format, what 'enhanced' means, or whether any filtering or sorting applies. This is a significant gap for an agent needing to understand the tool's output.
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 documents all three parameters (from, to, relationType) with descriptions, and schema_description_coverage is 100%. The description adds no meaning beyond 'specific relation,' so the baseline 3 applies.
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 function: retrieving a specific relation with enhanced properties from the Memento knowledge graph. It uses a specific verb ('get') and names the resource ('specific relation'), making it distinct from mutation or history tools like create_relations or get_relation_history, though it does not explicitly compare to alternatives.
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: this tool is for retrieving a specific relation. It doesn't explicitly state when not to use it or mention alternatives, but the purpose is obvious enough for basic selection 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.
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. It discloses the mechanism (vector embeddings and similarity) but does not state that the operation is read-only/non-destructive, nor does it mention any limitations, rate limits, or output behavior. The safety profile is not explicitly disclosed.
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, focused sentence that directly states the tool's purpose without extraneous information. It is front-loaded and efficient.
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 six parameters, no annotations, and no output schema, yet the description only provides the basic purpose. It lacks context on result format, default behaviors, or how this search integrates with the knowledge graph. The schema covers parameter details, but higher-level context is missing.
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 descriptions cover all six parameters with detailed explanations, so the description adds no additional parameter semantics beyond the schema. The 100% coverage supports the 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 defines the tool as a semantic search over Memento MCP entities using vector embeddings, making it distinct from the keyword-based sibling tools like search_nodes. The verb 'Search' and resource 'entities' are specific.
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 the tool is for semantic queries but does not explicitly state when to use it over alternatives like search_nodes, nor does it mention any exclusions or crossover conditions. Without naming sibling tools, guidance is limited to the implied semantic use case.
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 for behavioral disclosure. It states only that the tool 'gets' an embedding, implying a read operation, but does not disclose return format, error behavior, or any side effects. This is minimal beyond the basic action.
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 that front-loads the key action and resource. Every word contributes to clarity without 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?
For a simple one-parameter getter, the description provides adequate purpose but lacks completeness because no output schema exists, so return format is not described, and no usage guidelines or error behavior are mentioned. It is minimally viable but with clear gaps.
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 fully describes the sole parameter (entity_name) at 100% coverage. The description adds no additional meaning beyond the schema, so baseline score of 3 applies.
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 uses a specific verb ('Get') and resource ('the vector embedding for a specific entity') clearly distinguishing it from siblings like read_graph or get_entity_history. It precisely defines what the tool does.
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 (retrieve an embedding when needed) but does not explicitly mention when to use this tool over alternatives like semantic_search. No exclusions or alternatives are named, leaving usage guidance implied rather than explicit.
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 only states the action ('Get') without describing read-only nature, response format, pagination, or any limits. This is a minimal disclosure that does not inform the agent about what to expect beyond the basic operation.
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-structured sentence with no wasted words. It is appropriately concise and front-loaded with the key verb and resource.
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?
For a simple one-parameter tool, the description is minimally viable, but it lacks information about the return value (no output schema) and does not provide context on what 'version history' entails. Given the presence of siblings like get_relation_history, it could benefit from more contextual detail to guide the agent effectively.
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% (the only parameter entityName is fully described in the schema). The description adds no extra meaning beyond the schema, matching the baseline of 3 for full 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 tool's purpose with a specific verb ('Get') and resource ('version history of an entity'), distinguishing it from sibling tools like get_relation_history which target relations. The context 'from your Memento MCP knowledge graph memory' further clarifies scope.
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 retrieving an entity's version history but provides no explicit guidance on when to use this tool versus alternatives like get_relation_history or get_graph_at_time. There is no mention of when not to use it or any exclusions.
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 rephrases the tool name without adding operational details such as return format, potential side effects, timestamp validation, or performance implications. For a read operation, it is safe to assume non-destructiveness, but the description does not explicitly confirm or elaborate on 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, concise sentence with no redundant words. It earns its place by clearly stating the tool's purpose without waste.
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?
The tool is simple with one parameter, and the description covers its core function. However, there is no output schema, and the description does not explain what the response contains (e.g., full graph snapshot, node/relation lists). This leaves minor ambiguity but is still adequate for basic invocation.
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 fully documents the timestamp parameter (100% coverage), so the description does not need to elaborate. It adds no parameter-specific semantics, but none are necessary given the schema's clarity.
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 uses a specific verb ('Get') and resource ('knowledge graph memory') with a clear temporal qualifier ('as it existed at a specific point in time'). This distinguishes it from sibling tools like read_graph (current state) and get_decayed_graph (decay-based retrieval).
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 use for historical queries but does not explicitly contrast with alternatives such as read_graph or get_entity_history. The 'as it existed at a specific point in time' hints at the use case but leaves it to the agent to infer when to use this tool over siblings.
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 present, so the description carries the burden. 'Read' communicates a non-destructive operation and 'entire' indicates broad scope, but it does not disclose potential performance costs, response size, or exact return format, leaving some behavioral ambiguity.
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, clear sentence that is front-loaded with the action and resource. Every word contributes to the meaning, with no redundancy or filler.
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?
For a simple, no-required-parameter graph read operation, the description adequately states scope and intent. The lack of an output schema is acceptable given the straightforward 'read entire graph' semantics, though a note on return format would make it slightly more complete.
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 schema fully describes the lone dummy parameter with 100% coverage, and the description adds no parameter-specific information. A baseline of 3 is appropriate because the schema already handles parameter 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 uses the specific verb 'Read' and identifies the resource as the 'entire Memento MCP knowledge graph memory system', making the tool's scope explicit. It clearly distinguishes this from sibling tools like search_nodes and get_graph_at_time, which imply filtered or temporal subsets.
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 about when to use this tool versus alternatives. It does not mention that search_nodes or get_graph_at_time could be better for specific queries, nor does it state exclusions such as 'use only when you need the full graph'.
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 does disclose a key side effect: associated relations are also deleted. However, it does not mention what happens to observations attached to the entities, whether deletion is permanent, or any other side effects. This is a partial disclosure.
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 sentence that is front-loaded with the action and scope. Every word contributes meaning, with no redundant or filler content.
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 simple one-parameter interface, the description covers the core operation, but it leaves ambiguity about the fate of observations and whether deletion is reversible. With no output schema and no annotations, these omissions prevent a higher score.
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 fully describes entityNames as 'An array of entity names to delete' (100% schema coverage). The description adds no additional meaning for the parameter, so the baseline of 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 uses a specific verb ('Delete') and identifies the resource ('multiple entities and their associated relations') within the Memento MCP knowledge graph. It clearly distinguishes this tool from siblings like delete_relations by noting the cascading deletion of associated relations.
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 this tool should be used when both entities and their relations need to be deleted, versus using delete_relations separately. However, it does not explicitly state when to prefer this tool over alternatives, list exclusions, or mention prerequisites. The usage guidance is implied rather than explicit.
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, the description carries the burden of behavioral disclosure. It clearly states the core behavior—returning the knowledge graph with confidence values decayed by time—and the use of 'Get' implies a read-only operation. However, it does not elaborate on return format, potential side effects, or edge cases, though none are strongly suggested.
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, front-loaded sentence that conveys the essential purpose without any unnecessary words. Every phrase contributes to understanding the tool's function, 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 lack of output schema and annotations, the description adequately conveys the main behavior and the optional override parameters. It is sufficient for a simple retrieval tool, though it could mention the default half-life calculation or the graph's composition (e.g., entities and relations).
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 both decay_factor and reference_time already described in the schema. The description adds only the context that decay is time-based but does not provide additional meaning beyond the parameter descriptions themselves, so it meets the 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 uses a specific verb 'Get' with a clear resource 'Memento MCP knowledge graph memory' and specifies the unique aspect 'with confidence values decayed based on time'. This distinguishes it from sibling tools like get_graph_at_time, which focuses on temporal snapshots rather than confidence decay.
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 when time-decayed confidence values are needed, but it does not explicitly state when to use this tool versus alternatives like read_graph or get_graph_at_time. No exclusions or alternative recommendations are provided, so guidance is only implicit.
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:

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

Score Badge

Copy to your README.md:

[![mnemosyne-mcp MCP server](https://glama.ai/mcp/servers/zhadyz/mnemosyne-mcp/badges/score.svg)](https://glama.ai/mcp/servers/zhadyz/mnemosyne-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/zhadyz/mnemosyne-mcp'

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