memory-mcp

by jmars

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: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation: create/delete entities, add/delete observations, create/delete relations, search via token match vs fuzzy name match, open specific nodes vs read full graph vs traverse vs recent. The descriptions clearly differentiate similar-sounding tools like search_nodes and search_similar.
Naming Consistency4/5
The naming predominantly follows a verb_noun snake_case pattern (create_entities, delete_relations, search_nodes). Minor deviations exist with 'recent' and 'traverse' which are single-word verbs, but they are still descriptive and do not disrupt overall consistency.
Tool Count5/5
With 12 tools, the server is well-scoped for a knowledge graph memory system. Each tool serves a clear purpose, and the count is within the ideal range for a domain-specific MCP server.
Completeness5/5
The tool set provides comprehensive coverage for managing a knowledge graph: create/delete entities, add/delete observations, create/delete relations, multiple retrieval methods (specific, full graph, traversal, recent, search), and fuzzy search. Update operations are supported via add/delete observations and create/delete relations, covering the full lifecycle without dead ends.
Average 3.9/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It discloses that the tool returns full entity details including observations and timestamps, which is useful. However, it does not explicitly state that the operation is read-only, nor does it describe behavior for non-existent names, error handling, or potential side effects.
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 compact sentences. The first states the action and target, the second outlines the return content. Every word contributes meaning; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema. The description covers the primary purpose and return content, which is sufficient for basic invocation. Minor gaps include lack of alternative guidance and absence of error behavior, but these are not critical given the low complexity and existing output schema.
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 has no descriptions for the 'names' parameter (0% coverage). The description compensates partially by noting the nodes are opened 'by their names', clarifying that the parameter contains node identities. It does not add details about name format, case sensitivity, or handling of duplicate names, but the single simple parameter is reasonably clarified.
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 opens specific nodes in the knowledge graph by name and returns full entity details. It uses a specific verb ('open') and resource ('nodes in the knowledge graph'), with scope defined by 'by their names'. However, it does not explicitly differentiate from sibling tools like search_nodes or traverse, which serve related lookup purposes.
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 search_nodes or traverse. It implies that the user must know exact node names, but it does not state this as a prerequisite or suggest searching when names are unknown. There is no mention of exclusions or preferred scenarios.
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 explains the action but does not disclose side effects (e.g., appending vs overwriting), error conditions (e.g., missing entity), permissions, or return behavior. This is sparse 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 two sentences, front-loaded with the primary action and immediately followed by required item structure. Every word earns its place, with no filler or 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?
The tool is simple with a single parameter and an output schema present, so the description need not explain return values. However, it lacks details on entity existence prerequisites, failure modes, and mutation semantics, making it adequate but not complete given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage because the inner objects are not defined. The description adds essential meaning by specifying each item must have 'entityName' (str) and 'contents' (list[str]), significantly compensating 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 states the specific verb 'Add' and resource 'observations to existing entities in the knowledge graph', clearly distinguishing it from siblings like create_entities (adds entities) and create_relations (adds 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 usage for adding observations to existing entities, and the phrase 'existing entities' hints at a prerequisite. However, it does not explicitly mention when not to use it or name alternatives, 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?
No annotations are provided, so the description carries the full burden. It only lists required fields but does not disclose behaviors such as idempotency, error handling, duplicate handling, or return format. This is a significant gap for a mutation 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 two sentences: the first states the purpose, the second enumerates required fields. It is concise, front-loaded, and every sentence contributes meaning without wasted words.
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 an output schema exists, so return values need no explanation. However, the description lacks usage guidance and behavioral context, and with no annotations, the agent is left with incomplete information about side effects or failure modes. This is adequate but has clear 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?
The schema shows only a single 'entities' array with no property descriptions (coverage 0%). The description compensates by explicitly specifying the required fields (name, entityType, observations) and their types, providing essential meaning beyond the schema's permissive additionalProperties.
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 'Create multiple new entities' with a specific verb and resource, and the context of a knowledge graph distinguishes it from siblings like create_relations and add_observations. It unambiguously communicates 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 usage context is implied by the tool name and the sibling tools (e.g., creating entities vs. relations/observations), but the description does not explicitly state when to use this tool over alternatives or any exclusions. It gives no direct 'when-to-use' guidance beyond the basic action.
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 only states the required fields for each relation, but does not reveal any behavioral traits such as whether the operation is idempotent, whether existing relations are overwritten or duplicated, how partial failures are handled, or any permission requirements. The mutation side effect is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two sentences to state the core purpose and required fields. It is front-loaded and every sentence earns its place, with no extraneous 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?
For a tool with a single parameter and an output schema, the description provides the essential structure of the relations. It does not mention potential edge cases like entity existence validation, duplicate handling, or error behavior, which could be relevant for an agent invoking the tool. The description is adequate but lacks some contextual depth that would make it fully 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 input schema provides no property descriptions (coverage 0%), so the description must compensate. The description adds meaning by specifying that each relation must have 'from (str), to (str), relationType (str)', which clarifies the array item structure. However, it does not explain optional properties, examples, or any constraints on relationType, leaving gaps in parameter understanding.
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 function: 'Create multiple new relations between entities in the knowledge graph.' This is a specific verb+resource that distinguishes it from siblings like create_entities (entities vs relations) and delete_relations (inverse operation). 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage context: it is for creating relations, and sibling tools make it obvious that create_entities is for entities and delete_relations for removal. However, it does not explicitly state when to use this tool over alternatives or exclude any cases. The context is clear but lacks explicit when-not guidance.
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 full burden. It discloses the destructive action and the cascading deletion of associated relations, but does not mention irreversibility, partial failures, or whether observations are affected. This is moderate but not exhaustive.
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 unnecessary words. It efficiently conveys purpose and scope, 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.
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 an output schema, so return values need not be explained. However, the description leaves ambiguity about the effect on observations and lacks error-handling or prerequisite details. It is adequate but not comprehensive.
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 only parameter, entityNames, is not explicitly described, but the phrase 'multiple entities' directly maps to it. Since schema coverage is 0%, the description compensates somewhat, but it adds no details about matching behavior or constraints beyond what the schema shows.
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), the resource (entities), and the scope (multiple entities and their associated relations). It distinguishes from sibling tools like delete_observations and delete_relations by focusing on entities and cascading relation deletion.
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 deleting entities but does not explicitly mention when not to use it or compare with alternatives like delete_relations. Sibling names are present, but no direct guidance is given.
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 full burden. It discloses the depth limit (max 3) and return behavior (all entities within N hops), but does not mention side effects, error handling for nonexistent start_node, or performance considerations. It adds some useful context but lacks deeper behavioral 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 introductory sentence followed by a clean argument list. There is no filler; every sentence contributes useful information, including parameter defaults and limits.
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 relatively simple tool with two parameters and an output schema, the description adequately covers core purpose and parameters. However, it omits usage guidance and return format details (though output schema exists). Overall, it is reasonably complete for tool invocation.
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 0%, so the description must compensate. It fully explains both parameters: start_node is the entity to start from, and depth specifies the number of hops with default 1 and max 3. This adds meaning well beyond the raw schema 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 uses a specific verb ('Traverse') and resource ('the graph'), clearly stating the start node and the N-hop scope. It effectively distinguishes the tool from siblings like read_graph (whole-graph read) and search_nodes (keyword 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?
No guidance is provided on when to use this tool versus alternatives such as read_graph or open_nodes. There are no exclusions or explicit context about ideal use cases; the description only states what the tool does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully explain behavior. It clearly states that only created/updated items are returned (not deletions) and defines the time window semantics. However, it does not disclose potential ordering, pagination, or any side effects (though none are expected). It adds some transparency but could go further in describing result 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 extremely concise: one opening sentence and a two-line docstring for the parameter. No unnecessary words or repetition. It is well-structured with the main purpose first, making it easy to scan.
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 low complexity (one parameter, no nested objects) and the presence of an output schema, the description appropriately covers what is returned and the time filter. It lacks details like sorting or limits, but for a simple time-based query, the provided information is sufficient. Sibling tools are diverse enough that the unique scope is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides the parameter name and type with a default, but no description. The description compensates by explaining that 'hours' is a look-back window and adding a maximum of 720 that is not present in the schema. This adds significant meaning beyond the schema for the single parameter.
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 'Return' and names the exact resources (entities, relations, observations) with a clear time-based scope. This distinctly separates it from sibling tools like delete_entities or search_nodes, making its purpose immediately obvious.
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 time-based queries by explaining the look-back window and default/max values, but it does not explicitly state when to use this tool instead of alternatives like search_nodes or read_graph. No 'when not to use' guidance is given, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses that matching is case-insensitive and token-based, and that it returns matching entities with observations. It does not mention any limitations (e.g., pagination, fuzzy matching, read-only nature) but the disclosed behavior goes beyond the schema and is genuinely informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the action and target, the second explains the matching behavior and return. No filler or redundant detail. Each sentence earns its place.
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 one-parameter search tool with an output schema, the description adequately covers the purpose, behavior, and output. It does not address edge cases like empty results or pagination, but these are unlikely to be critical given the tool's simplicity and the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter with zero description coverage. The description compensates by explaining that 'query' is used for case-insensitive token matching across entity names, types, and observation content. However, it does not clarify token matching semantics (e.g., substring vs. whole word) or expected formatting, so it adds some but not complete meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Search for nodes in the knowledge graph.' It further specifies the matching scope (entity names, types, observation content) and return value (matching entities with their observations), distinguishing it from sibling tools like search_similar or traverse.
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 keyword-based search across entity fields, but it does not explicitly contrast with sibling tools like search_similar or traverse, nor does it mention when not to use it. The context is clear but lacks exclusions or alternative selection guidance, making it a minimum viable score.
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 full burden. It discloses the exact-content-match requirement for observations, which is a valuable behavioral detail, but does not mention side effects, error handling, or destructive consequences beyond the obvious delete 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 exactly two sentences: the first fronts the purpose, the second provides parameter structure. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a focused deletion tool with a single parameterized array, the description covers the essential structure and behavior. Return values are likely documented by the output schema, but the description does not mention preconditions (e.g., entity existence) or failure behavior.
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?
The input schema is highly generic (array of objects with additionalProperties true), with 0% schema description coverage. The description compensates fully by specifying the required nested fields (entityName and observations), their types, and the exact match semantics, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes specific observations from entities in a knowledge graph, using the specific verb 'delete' and the resource 'observations'. This distinguishes it from sibling tools like delete_entities and delete_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?
No explicit when-to-use or alternative recommendations are provided. The description implies its usage through the focus on observations, but it does not mention any exclusions or contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It discloses a key behavioral nuance: if relationType is omitted, all relations between from and to are deleted. It also specifies required fields. However, it does not mention error handling, reversibility, or side effects on associated entities.
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 two-sentence description is efficient: the first declares the core action, the second specifies requirements and the optional-relationType behavior. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with one array parameter, the description covers the essential behavior and the critical nuance about relationType. It relies on the existing output schema for return values. It could elaborate on error behavior or atomicity, but it is sufficiently complete for basic selection and invocation.
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?
The schema only defines a 'relations' array with no inner structure (0% coverage). The description compensates by specifying each relation must have from (str), to (str), and relationType (str), and clarifies the effect of omitting relationType. This fully disambiguates the 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 states 'Delete multiple relations from the knowledge graph' with a specific verb and resource, and distinguishes from sibling delete tools (delete_entities, delete_observations) by explicitly targeting 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 usage for deleting relations, but does not explicitly provide guidance on when to use it versus alternatives or when not to use it. The mention of multiple relations and the optional relationType provides some context but lacks exclusions or alternative tool references.
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 full burden. It explains the threshold parameter and its range, but does not disclose details such as result ordering, case sensitivity, or what happens with no matches. The core behavior is clear, but additional behavioral context is limited.
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 brief and front-loaded with the main purpose, followed by a clean Args list. Every sentence adds value, with no fluff.
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 search tool with an output schema, the description covers the essentials of purpose and parameters. However, it omits any mention of return behavior (e.g., sorting or result limits), which would be useful for an agent to set expectations. It is adequate but not exceptional.
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?
The schema provides no parameter descriptions (0% coverage), but the description fully compensates by explaining both parameters: name is fuzzy matched, and threshold is the minimum similarity score 0.0–1.0 with a default of 0.3. This is excellent parameter documentation.
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 performs fuzzy search on entity names using trigram similarity, specifying both the resource (entity names) and the operation (fuzzy search). It distinguishes itself from sibling tools like search_nodes by the fuzzy matching approach.
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 fuzzy entity name matching but does not explicitly mention when to use it over alternatives like search_nodes or when not to use it. No exclusions or alternatives are provided, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It reveals the important trait that the entire graph is loaded into memory and may be large, which is critical for performance considerations. It also clarifies the return contents. This goes beyond a simple 'read' statement, though it doesn't cover every possible behavioral facet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the purpose, specify returns, and add a critical note about memory. Every sentence earns its place with no fluff or redundancy.
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?
For a no-parameter read tool with an output schema, the description is fully complete. It explains what is returned and warns about the memory footprint, which is the primary caveat. The existence of an output schema covers return-value details, and siblings provide alternatives for more targeted operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, making parameter semantics trivially complete. The baseline for no parameters is 4, and since there is nothing to clarify, the description need not add extra information.
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 'Read the entire knowledge graph' with a specific verb and resource, and further specifies it returns 'all entities with observations and all relations.' It distinguishes itself from siblings like search_nodes and traverse by indicating it reads everything at once.
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 full-graph access and warns that it loads the full graph into memory, which may be large. However, it never explicitly mentions alternative tools for partial queries or gives when-to-use/when-not-to-use guidance, leaving the agent to infer when this tool is appropriate.
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:

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

Score Badge

Copy to your README.md:

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

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