Knowledge Graph Memory Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but some overlap exists: 'open_nodes' and 'search_nodes' both involve accessing nodes, which could cause confusion. However, descriptions clarify that 'open_nodes' targets specific names while 'search_nodes' uses queries, reducing ambiguity. Other tools like 'add_observations' vs. 'create_entities' are clearly differentiated.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout, such as 'add_observations', 'create_entities', and 'delete_relations'. All tools use snake_case and clear verbs, making them predictable and easy to understand. There are no deviations in naming conventions.
Tool Count5/5
With 13 tools, the count is well-scoped for a knowledge graph memory server, covering operations like CRUD for entities, relations, observations, and lessons. Each tool appears to serve a specific function without redundancy, fitting the domain's complexity appropriately.
Completeness4/5
The tool set provides comprehensive coverage for knowledge graph management, including creation, reading, updating, and deletion of entities, relations, observations, and lessons. A minor gap is the lack of an 'update_entities' or 'update_relations' tool for modifying existing content, but agents can work around this by deleting and recreating. Core workflows are well-supported.
Average 2.9/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed 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 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

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 states the tool 'Get[s] relevant lessons' but doesn't disclose behavioral traits like whether it's read-only, requires authentication, has rate limits, returns structured data, or handles errors. For a tool with no annotations, this leaves significant gaps in understanding its operation.
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, efficient sentence that front-loads the core purpose. It avoids unnecessary words, but could be more structured by including key details like usage context or output format. Overall, it's appropriately sized with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (inference-based recommendations), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'relevant' entails, how lessons are selected, the return format, or error handling. For a recommendation tool with no structured support, more detail is needed 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?
The input schema has 100% description coverage, with one parameter 'context' documented as 'The current context to find relevant lessons for'. The description adds no additional meaning beyond this, as it only repeats 'based on the current context'. With high schema coverage, the baseline score of 3 is appropriate, as the schema already provides adequate parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get relevant lessons based on the current context' clearly states the verb 'Get' and resource 'lessons', but it's vague about what 'relevant' means and doesn't differentiate from sibling tools like 'search_nodes' or 'find_similar_errors'. It specifies the action but lacks precision in scope or method.
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 'search_nodes' or 'find_similar_errors'. The description implies usage based on 'current context' but doesn't specify scenarios, prerequisites, or exclusions, leaving the agent to guess when this is the appropriate choice.
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 this is a creation operation but doesn't mention permissions needed, whether entities are permanent or reversible, rate limits, or what happens on partial failure when creating multiple entities. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 7 words, front-loading the essential information with zero wasted words. Every word earns its place in communicating the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool that creates multiple entities with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what happens after creation, error conditions, or provide enough context for safe and effective use despite the tool's apparent complexity.
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%, so the description must compensate but doesn't. It mentions 'entities' but provides no information about what constitutes an entity, what 'entityType' values are valid, or what 'observations' should contain. The single parameter 'entities' array remains largely unexplained beyond its name.
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 action ('Create') and resource ('multiple new entities in the knowledge graph'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_lesson' or 'create_relations', which also create things in the knowledge graph system, so it doesn't reach the highest score.
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 prerequisites, when not to use it, or how it differs from sibling tools like 'create_lesson' or 'add_observations', 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'find similar errors and their solutions' but doesn't clarify what 'similar' means (e.g., based on pattern matching, semantic similarity), how results are returned, or any limitations like rate limits or authentication needs. This leaves significant gaps in understanding the tool's 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to grasp 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?
Given the complexity (1 parameter with nested objects, no annotations, no output schema), the description is insufficient. It doesn't explain the input structure, output format, or behavioral details needed for effective use. For a tool that likely involves complex pattern matching and result retrieval, more context is required.
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%, so the schema provides no parameter descriptions. The tool description mentions 'errorPattern' implicitly but doesn't explain what it should contain or how it's used to find similar errors. It fails to compensate for the lack of schema documentation, leaving parameters largely undefined.
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 action ('Find') and target ('similar errors and their solutions in the knowledge graph'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_nodes' or 'get_lesson_recommendations', which might also involve searching or retrieving information from the knowledge graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'search_nodes' and 'get_lesson_recommendations' that might overlap in functionality, there's no indication of specific use cases, prerequisites, or exclusions for this tool.
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. While 'Add' implies a write/mutation operation, the description doesn't specify whether this requires special permissions, whether observations are appended or replace existing ones, what happens if entities don't exist, or any rate limits. This leaves significant behavioral 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, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a tool with one main parameter and gets straight to the point with zero wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It doesn't explain what constitutes valid observations, how they're stored, what the response looks like, or error conditions. Given the knowledge graph context and sibling tools indicating a complex system, more contextual information would be helpful.
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 description mentions 'observations' and 'entities' which aligns with the single parameter 'observations' containing entityName and contents arrays. However, with 0% schema description coverage, the description doesn't add meaningful details about parameter format, constraints, or examples beyond what's minimally implied. The baseline is 3 since the single parameter structure is relatively simple.
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 action ('Add new observations') and target ('to existing entities in the knowledge graph'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from its sibling 'delete_observations' or explain how it differs from 'create_entities' which might also involve observation creation.
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 like 'create_entities' (which might create entities with observations) or 'update_lesson_success' (which might involve observations). There's no mention of prerequisites, constraints, or typical scenarios for choosing this specific tool.
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. While 'Create' implies a write/mutation operation, the description doesn't address critical aspects: permission requirements, whether creation is idempotent or can overwrite existing lessons, what happens on failure, or what the response contains. For a complex creation tool with nested objects, this leaves significant behavioral uncertainty.
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 with zero wasted words. It front-loads the core action ('Create a new lesson') and immediately specifies the source material. Every word contributes essential information, making it optimally concise for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with complex nested parameters (1 parameter with 6+ sub-properties), no annotations, and no output schema, the description is insufficient. It doesn't explain the creation workflow, success/failure behavior, return values, or how the input structure relates to the described 'error and its solution' concept. The agent must rely entirely on the raw schema without contextual guidance.
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 description mentions the parameter's purpose ('from an error and its solution'), which provides high-level context for the 'lesson' object. However, with 0% schema description coverage and 1 complex nested parameter containing multiple sub-properties, the description doesn't explain the structure, required fields beyond what the schema shows, or how 'error' and 'solution' map to specific properties like 'errorPattern' and 'verificationSteps'. It adds minimal value beyond the schema's structural definition.
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 verb 'Create' and the resource 'new lesson', specifying it's created 'from an error and its solution'. This distinguishes it from generic creation tools like 'create_entities' by focusing on error-based lesson creation. However, it doesn't explicitly differentiate from 'update_lesson_success' which might also involve lesson modifications.
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 like 'create_entities' (for general entity creation) or 'update_lesson_success' (for modifying existing lessons). It mentions the source material ('from an error and its solution') but doesn't specify prerequisites, constraints, or appropriate contexts for invocation.
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 states this is a creation tool (implying mutation) but doesn't disclose behavioral traits like required permissions, whether it's idempotent, error handling, or rate limits. The 'active voice' note is stylistic, not behavioral. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly state the tool's purpose and a constraint. It's front-loaded with the core functionality and wastes no words, making it efficient and easy to parse.
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 a mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks crucial context like what happens on success/failure, return values, error conditions, or prerequisites. The 'active voice' note doesn't address these 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 description adds no parameter semantics beyond what the input schema provides. Schema description coverage is 0%, but the schema itself documents the 'relations' array structure with 'from', 'to', and 'relationType'. The description doesn't compensate for the coverage gap by explaining parameter meanings, formats, or examples. Baseline 3 is appropriate as the schema does the heavy lifting.
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 verb ('create') and resource ('multiple new relations between entities in the knowledge graph'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_entities' or 'delete_relations', which would require more specific context about when to use each.
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 like 'create_entities' or 'delete_relations'. It mentions 'relations should be in active voice', which is a stylistic constraint but not a usage guideline. There's no explicit when/when-not 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.
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 states the tool deletes entities and relations, implying a destructive mutation, but lacks details on permissions, irreversibility, side effects, or error handling. This is inadequate for a destructive operation with zero annotation coverage.
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, efficient sentence that directly states the tool's purpose without redundancy. It is front-loaded and wastes no words, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is insufficient. It lacks critical context such as confirmation prompts, return values, error cases, or impact on related data, leaving significant gaps for safe and effective use.
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 the parameter 'entityNames' well-documented in the schema. The description adds no additional meaning beyond implying the parameter is an array of entity names, which the schema already covers, so it meets the baseline for high schema coverage.
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 action ('Delete') and target ('multiple entities and their associated relations from the knowledge graph'), which is specific and unambiguous. However, it does not explicitly differentiate from sibling tools like 'delete_observations' or 'delete_relations', which handle different resource types, so it misses full sibling distinction.
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 does not mention prerequisites, exclusions, or compare with siblings like 'delete_observations' or 'delete_relations', leaving the agent without context for 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?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Delete' implies a destructive mutation, it doesn't specify whether deletions are permanent, reversible, require specific permissions, or have side effects on related data. For a destructive operation with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a tool with one main parameter and gets straight to the point with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't address critical context like what happens after deletion, error conditions, authentication requirements, or how to verify successful deletion. The tool's complexity warrants more complete disclosure.
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 description mentions 'specific observations' and 'entities in the knowledge graph', which aligns with the 'deletions' parameter structure containing 'entityName' and 'observations' arrays. However, with 0% schema description coverage, the description doesn't fully compensate by explaining parameter formats, constraints, or examples. The baseline is appropriate given the partial semantic alignment.
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 action ('Delete') and target ('specific observations from entities in the knowledge graph'), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'delete_entities' or 'delete_relations', which handle different resource types in the same system.
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 sibling tools like 'delete_entities' (for deleting entire entities) or 'add_observations' (for adding rather than deleting), nor does it specify prerequisites or constraints for deletion operations.
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 the destructive action ('Delete') but lacks critical details: whether this is irreversible, what permissions are needed, if there are rate limits, or what happens on partial failures. For a mutation tool with zero annotation coverage, this is a significant gap.
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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after deletion (e.g., success/failure response, error handling), nor does it address behavioral risks like irreversibility. Given the complexity and lack of structured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the 'relations' parameter and its nested properties. The description adds no additional semantic context beyond implying bulk deletion, which aligns with the schema. This meets the baseline for high schema coverage.
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 action ('Delete') and target resource ('multiple relations from the knowledge graph'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'delete_entities' or 'delete_observations', which prevents a perfect score.
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 like 'delete_entities' or 'delete_observations'. It lacks context about prerequisites, such as whether relations must exist or be deletable, and offers no explicit when-not-to-use warnings.
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 states the action ('open') but doesn't disclose behavioral traits such as what 'open' entails (e.g., retrieving details, expanding nodes, or accessing metadata), whether it's read-only or has side effects, error handling for non-existent nodes, or any rate limits. The description is minimal and lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the main action and resource. However, it could be slightly more informative by including key usage details without sacrificing brevity, keeping it appropriately sized for its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (involving node retrieval in a knowledge graph), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'open' means operationally, what data is returned, or how it differs from siblings like 'search_nodes'. For a tool with no structured behavioral hints, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'names' parameter fully documented as 'An array of entity names to retrieve'. The description adds no additional meaning beyond this, such as format examples (e.g., case sensitivity) or constraints (e.g., maximum array size). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract either.
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 action ('open') and resource ('nodes in the knowledge graph'), with specificity about targeting by 'their names'. It distinguishes from siblings like 'search_nodes' (which likely searches rather than opens) and 'read_graph' (which likely reads the entire graph). However, it doesn't explicitly differentiate from 'create_entities' or 'update_lesson_success', which could involve similar resources but different operations.
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 prerequisites (e.g., nodes must exist), exclusions (e.g., not for creating nodes), or compare to siblings like 'search_nodes' (for finding nodes) or 'read_graph' (for broader access). This leaves the agent to infer usage from the tool name alone.
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 states the tool searches nodes but doesn't describe key behaviors such as whether it's read-only or mutative, what permissions are required, how results are returned (e.g., pagination, sorting), or any rate limits. This leaves significant gaps for an agent to understand operational traits.
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 efficiently conveys the core purpose without any wasted words. It is appropriately sized and front-loaded, making it easy 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?
Given the complexity of a search operation in a knowledge graph with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., read-only nature, result format) and doesn't compensate for the absence of structured data, making it inadequate for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'query' parameter well-documented in the schema. The description adds minimal value beyond the schema by mentioning the query is used to match against 'entity names, types, and observation content', which slightly elaborates on the schema's description. This meets the baseline of 3 for high schema coverage.
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 with a specific verb ('Search') and resource ('nodes in the knowledge graph'), and it specifies the search scope ('based on a query'). However, it doesn't explicitly differentiate from sibling tools like 'find_similar_errors' or 'read_graph', which might also involve searching or reading operations in the knowledge graph context.
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 when to prefer 'search_nodes' over siblings like 'find_similar_errors' (which might search for errors) or 'read_graph' (which might retrieve graph data without query-based filtering), nor does it specify any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Update' which implies a mutation, but fails to specify permissions needed, whether changes are reversible, rate limits, or response format. This leaves 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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand 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?
Given the tool's mutation nature, lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling, return values, or integration with sibling tools, leaving the agent with insufficient context for safe and effective use.
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 description coverage is 100%, so the input schema already documents both parameters ('lessonName' and 'success') adequately. The description adds minimal value by implying the context ('after applying its solution') but doesn't provide additional syntax or format details beyond the schema.
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 action ('Update') and resource ('success rate of a lesson') with context ('after applying its solution'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'create_lesson' or 'get_lesson_recommendations' in terms of when to update versus create or retrieve.
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 minimal guidance by implying usage 'after applying its solution,' but it lacks explicit when-to-use rules, alternatives (e.g., vs. 'create_lesson' for initial setup), or prerequisites. No clear boundaries or comparisons to sibling tools are stated.
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 states 'Read' which implies a read-only operation, but doesn't specify aspects like whether it returns all nodes/relations, potential performance impacts for large graphs, or error conditions. This leaves significant gaps for a tool that presumably accesses a knowledge graph.
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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it immediately understandable without any fluff or 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?
Given the complexity of reading a knowledge graph, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'entire' means (e.g., all nodes, relations, metadata), the return format, or any limitations, which are critical for an AI agent to use this tool effectively.
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 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and the baseline for 0 parameters is 4, as it avoids unnecessary detail while matching the schema.
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 action ('Read') and resource ('the entire knowledge graph'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'search_nodes' or 'open_nodes' that might also involve reading graph data, 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. With siblings like 'search_nodes' and 'open_nodes' that might offer more targeted reading, there's no indication of when this tool is preferred (e.g., for comprehensive retrieval vs. filtered queries).
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

memories-with-lessons-mcp-server MCP server

Copy to your README.md:

[![memories-with-lessons-mcp-server MCP server](https://glama.ai/mcp/servers/T1nker-1220/memories-with-lessons-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/T1nker-1220/memories-with-lessons-mcp-server)

Score Badge

Copy to your README.md:

[![memories-with-lessons-mcp-server MCP server](https://glama.ai/mcp/servers/T1nker-1220/memories-with-lessons-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/T1nker-1220/memories-with-lessons-mcp-server)

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/T1nker-1220/memories-with-lessons-mcp-server'

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