Skip to main content
Glama
enesjakozh
T1nker-1220

Knowledge Graph Memory Server

by T1nker-1220
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

Knowledge Graph Memory Server

A basic implementation of persistent memory using a local knowledge graph. This lets Claude remember information about the user across chats and learn from past errors through a lesson system.

Core Concepts

Entities

Entities are the primary nodes in the knowledge graph. Each entity has:

  • A unique name (identifier)

  • An entity type (e.g., "person", "organization", "event")

  • A list of observations

Example:

{
  "name": "John_Smith",
  "entityType": "person",
  "observations": ["Speaks fluent Spanish"]
}

Relations

Relations define directed connections between entities. They are always stored in active voice and describe how entities interact or relate to each other.

Example:

{
  "from": "John_Smith",
  "to": "Anthropic",
  "relationType": "works_at"
}

Observations

Observations are discrete pieces of information about an entity. They are:

  • Stored as strings

  • Attached to specific entities

  • Can be added or removed independently

  • Should be atomic (one fact per observation)

Example:

{
  "entityName": "John_Smith",
  "observations": [
    "Speaks fluent Spanish",
    "Graduated in 2019",
    "Prefers morning meetings"
  ]
}

Lessons

Lessons are special entities that capture knowledge about errors and their solutions. Each lesson has:

  • A unique name (identifier)

  • Error pattern information (type, message, context)

  • Solution steps and verification

  • Success rate tracking

  • Environmental context

  • Metadata (severity, timestamps, frequency)

Example:

{
  "name": "NPM_VERSION_MISMATCH_01",
  "entityType": "lesson",
  "observations": [
    "Error occurs when using incompatible package versions",
    "Affects Windows environments specifically",
    "Resolution requires version pinning"
  ],
  "errorPattern": {
    "type": "dependency",
    "message": "Cannot find package @shadcn/ui",
    "context": "package installation"
  },
  "metadata": {
    "severity": "high",
    "environment": {
      "os": "windows",
      "nodeVersion": "18.x"
    },
    "createdAt": "2025-02-13T13:21:58.523Z",
    "updatedAt": "2025-02-13T13:22:21.336Z",
    "frequency": 1,
    "successRate": 1.0
  },
  "verificationSteps": [
    {
      "command": "pnpm add shadcn@latest",
      "expectedOutput": "Successfully installed shadcn",
      "successIndicators": ["added shadcn"]
    }
  ]
}

Related MCP server: Knowledge Graph Memory Server

API

Tools

  • create_entities

    • Create multiple new entities in the knowledge graph

    • Input: entities (array of objects)

      • Each object contains:

        • name (string): Entity identifier

        • entityType (string): Type classification

        • observations (string[]): Associated observations

    • Ignores entities with existing names

  • create_relations

    • Create multiple new relations between entities

    • Input: relations (array of objects)

      • Each object contains:

        • from (string): Source entity name

        • to (string): Target entity name

        • relationType (string): Relationship type in active voice

    • Skips duplicate relations

  • add_observations

    • Add new observations to existing entities

    • Input: observations (array of objects)

      • Each object contains:

        • entityName (string): Target entity

        • contents (string[]): New observations to add

    • Returns added observations per entity

    • Fails if entity doesn't exist

  • delete_entities

    • Remove entities and their relations

    • Input: entityNames (string[])

    • Cascading deletion of associated relations

    • Silent operation if entity doesn't exist

  • delete_observations

    • Remove specific observations from entities

    • Input: deletions (array of objects)

      • Each object contains:

        • entityName (string): Target entity

        • observations (string[]): Observations to remove

    • Silent operation if observation doesn't exist

  • delete_relations

    • Remove specific relations from the graph

    • Input: relations (array of objects)

      • Each object contains:

        • from (string): Source entity name

        • to (string): Target entity name

        • relationType (string): Relationship type

    • Silent operation if relation doesn't exist

  • read_graph

    • Read the entire knowledge graph

    • No input required

    • Returns complete graph structure with all entities and relations

  • search_nodes

    • Search for nodes based on query

    • Input: query (string)

    • Searches across:

      • Entity names

      • Entity types

      • Observation content

    • Returns matching entities and their relations

  • open_nodes

    • Retrieve specific nodes by name

    • Input: names (string[])

    • Returns:

      • Requested entities

      • Relations between requested entities

    • Silently skips non-existent nodes

Lesson Management Tools

  • create_lesson

    • Create a new lesson from an error and its solution

    • Input: lesson (object)

      • Contains:

        • name (string): Unique identifier

        • entityType (string): Must be "lesson"

        • observations (string[]): Notes about the error and solution

        • errorPattern (object): Error details

          • type (string): Category of error

          • message (string): Error message

          • context (string): Where error occurred

          • stackTrace (string, optional): Stack trace

        • metadata (object): Additional information

          • severity ("low" | "medium" | "high" | "critical")

          • environment (object): System details

          • frequency (number): Times encountered

          • successRate (number): Solution success rate

        • verificationSteps (array): Solution verification

          • Each step contains:

            • command (string): Action to take

            • expectedOutput (string): Expected result

            • successIndicators (string[]): Success markers

    • Automatically initializes metadata timestamps

    • Validates all required fields

  • find_similar_errors

    • Find similar errors and their solutions

    • Input: errorPattern (object)

      • Contains:

        • type (string): Error category

        • message (string): Error message

        • context (string): Error context

    • Returns matching lessons sorted by success rate

    • Uses fuzzy matching for error messages

  • update_lesson_success

    • Update success tracking for a lesson

    • Input:

      • lessonName (string): Lesson to update

      • success (boolean): Whether solution worked

    • Updates:

      • Success rate (weighted average)

      • Frequency counter

      • Last update timestamp

  • get_lesson_recommendations

    • Get relevant lessons for current context

    • Input: context (string)

    • Searches across:

      • Error type

      • Error message

      • Error context

      • Lesson observations

    • Returns lessons sorted by:

      • Context relevance

      • Success rate

    • Includes full solution details

File Management

The server now handles two types of files:

  • memory.json: Stores basic entities and relations

  • lesson.json: Stores lesson entities with error patterns

Files are automatically split if they exceed 1000 lines to maintain performance.

Cursor MCP Client Setup

To integrate this memory server with Cursor MCP client, follow these steps:

  1. Clone the Repository:

git clone [repository-url]
cd [repository-name]

  1. Install Dependencies:

pnpm install

  1. Build the Project:

pnpm build

  1. Configure the Server:

  • Locate the full path to the built server file: /path/to/the/dist/index.js

  • Start the server using Node.js: node /path/to/the/dist/index.js

  1. Activate in Cursor:

  • Use the keyboard shortcut Ctrl+Shift+P

  • Type "reload window" and select it

  • Wait a few seconds for the MCP server to activate

  • Select the stdio type when prompted

The memory server should now be integrated with your Cursor MCP client and ready to use.

Usage with Claude Desktop

Setup

Add this to your claude_desktop_config.json:

Docker

{
  "mcpServers": {
    "memory": {
      "command": "docker",
      "args": ["run", "-i", "-v", "claude-memory:/app/dist", "--rm", "mcp/memory"]
    }
  }
}

NPX

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-memory"
      ]
    }
  }
}

NPX with custom setting

The server can be configured using the following environment variables:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-memory"
      ],
      "env": {
        "MEMORY_FILE_PATH": "/path/to/custom/memory.json"
      }
    }
  }
}

  • MEMORY_FILE_PATH: Path to the memory storage JSON file (default: memory.json in the server directory)

System Prompt

The prompt for utilizing memory depends on the use case. Changing the prompt will help the model determine the frequency and types of memories created.

Here is an example prompt for chat personalization. You could use this prompt in the "Custom Instructions" field of a Claude.ai Project.

Follow these steps for each interaction:

1. User Identification:
   - You should assume that you are interacting with default_user
   - If you have not identified default_user, proactively try to do so.

2. Memory Retrieval:
   - Always begin your chat by saying only "Remembering..." and retrieve all relevant information from your knowledge graph
   - Always refer to your knowledge graph as your "memory"

3. Memory
   - While conversing with the user, be attentive to any new information that falls into these categories:
     a) Basic Identity (age, gender, location, job title, education level, etc.)
     b) Behaviors (interests, habits, etc.)
     c) Preferences (communication style, preferred language, etc.)
     d) Goals (goals, targets, aspirations, etc.)
     e) Relationships (personal and professional relationships up to 3 degrees of separation)

4. Memory Update:
   - If any new information was gathered during the interaction, update your memory as follows:
     a) Create entities for recurring organizations, people, and significant events
     b) Connect them to the current entities using relations
     b) Store facts about them as observations

Building

Docker:

docker build -t mcp/memory -f src/memory/Dockerfile .

License

This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.

New Tools

  • create_lesson

    • Create a new lesson from an error and its solution

    • Input: lesson (object)

      • Contains error pattern, solution steps, and metadata

      • Automatically tracks creation time and updates

      • Verifies solution steps are complete

  • find_similar_errors

    • Find similar errors and their solutions

    • Input: errorPattern (object)

      • Contains error type, message, and context

      • Returns matching lessons sorted by success rate

      • Includes related solutions and verification steps

  • update_lesson_success

    • Update success tracking for a lesson

    • Input:

      • lessonName (string): Lesson to update

      • success (boolean): Whether solution worked

    • Updates success rate and frequency metrics

  • get_lesson_recommendations

    • Get relevant lessons for current context

    • Input: context (string)

    • Returns lessons sorted by relevance and success rate

    • Includes full solution details and verification steps

BIG CREDITS TO THE OWNER OF THIS REPO FOR THE BASE CODE I ENHANCED IT WITH LESSONS AND FILE MANAGEMENT

Big thanks! https://github.com/modelcontextprotocol/servers jerome3o-anthropic https://github.com/modelcontextprotocol/servers/tree/main/src/memory

Available Tools

13 tools
add_observationsC

Add new observations to existing entities in the knowledge graph

ParametersJSON Schema
NameRequiredDescriptionDefault
observationsYes

TDQS

C2.9/5.0
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.

create_entitiesC

Create multiple new entities in the knowledge graph

ParametersJSON Schema
NameRequiredDescriptionDefault
entitiesYes

TDQS

C2.8/5.0
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.

create_lessonC

Create a new lesson from an error and its solution

ParametersJSON Schema
NameRequiredDescriptionDefault
lessonYes

TDQS

C2.9/5.0
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.

create_relationsC

Create multiple new relations between entities in the knowledge graph. Relations should be in active voice

ParametersJSON Schema
NameRequiredDescriptionDefault
relationsYes

TDQS

C2.9/5.0
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.

delete_entitiesC

Delete multiple entities and their associated relations from the knowledge graph

ParametersJSON Schema
NameRequiredDescriptionDefault
entityNamesYesAn array of entity names to delete

TDQS

C2.9/5.0
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.

delete_observationsC

Delete specific observations from entities in the knowledge graph

ParametersJSON Schema
NameRequiredDescriptionDefault
deletionsYes

TDQS

C2.9/5.0
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.

delete_relationsC

Delete multiple relations from the knowledge graph

ParametersJSON Schema
NameRequiredDescriptionDefault
relationsYesAn array of relations to delete

TDQS

C2.9/5.0
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.

find_similar_errorsC

Find similar errors and their solutions in the knowledge graph

ParametersJSON Schema
NameRequiredDescriptionDefault
errorPatternYes

TDQS

C2.8/5.0
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.

get_lesson_recommendationsC

Get relevant lessons based on the current context

ParametersJSON Schema
NameRequiredDescriptionDefault
contextYesThe current context to find relevant lessons for

TDQS

C2.6/5.0
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.

open_nodesC

Open specific nodes in the knowledge graph by their names

ParametersJSON Schema
NameRequiredDescriptionDefault
namesYesAn array of entity names to retrieve

TDQS

C2.9/5.0
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.

read_graphB

Read the entire knowledge graph

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
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.

search_nodesC

Search for nodes in the knowledge graph based on a query

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe search query to match against entity names, types, and observation content

TDQS

C2.9/5.0
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.

update_lesson_successC

Update the success rate of a lesson after applying its solution

ParametersJSON Schema
NameRequiredDescriptionDefault
lessonNameYesName of the lesson to update
successYesWhether the solution was successful

TDQS

C2.9/5.0
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.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.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.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Knowledge Graph Memory Server

    guinacio
    A
    license
    Not graded
    quality
    C
    maintenance
    A persistent memory system using a local knowledge graph that enables Claude to remember information about users across chats, with advanced search, graph traversal, and filtering capabilities for entities, relations, and observations.
    MIT

  • AGI MCP Server

    randyandrade
    F
    license
    B
    quality
    D
    maintenance
    Enables persistent memory for AI systems by providing tools for episodic, semantic, and procedural data storage through a vector-and-graph-enhanced database. It allows models to maintain long-term continuity using similarity search, thematic clustering, and identity tracking.
    24
    1

Appeared in Searches

Latest Blog Posts

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