Skip to main content
Glama
enesjakozh
yodakeisuke

Knowledge Graph Memory Server

by yodakeisuke
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

forked https://github.com/modelcontextprotocol/servers/tree/main

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.

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"
  ]
}

Related MCP server: CogniRepo

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 one or more keywords

    • Input: query (string)

      • Space-separated keywords (e.g., "budget utility")

      • Multiple keywords are treated as OR conditions

    • Searches across:

      • Entity names

      • Entity types

      • Subdomains

      • Observation content

    • Matching behavior:

      • Case-insensitive

      • Partial word matching

      • Any keyword can match any field

      • Returns entities matching ANY of the keywords

    • Returns matching entities and their relations

    • Example queries:

      • Single keyword: "budget"

      • Multiple keywords: "budget utility"

      • With special chars: "budget & utility"

  • open_nodes

    • Retrieve specific nodes by name

    • Input: names (string[])

    • Returns:

      • Requested entities

      • Relations between requested entities

    • Silently skips non-existent nodes

Usage with Claude Desktop

Setup

Add this to your claude_desktop_config.json:

Docker

{
  "mcpServers": {
    "memory": {
      "command": "docker",
      "args": ["run", "-i", "--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"
   - When searching your memory, you can use multiple keywords to find related information
   - Example searches:
     * Single concept: "programming"
     * Related concepts: "programming python"
     * Specific domain with role: "work engineer"

3. Memory Creation:
   - 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)
   - When storing information, use specific and descriptive keywords that will help in future searches

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
     c) Store facts about them as observations
     d) Use clear and searchable terms in entity names and observations to facilitate future retrieval

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.

Available Tools

9 tools
add_observationsB

Add new observations to existing entities in the knowledge graph

ParametersJSON Schema
NameRequiredDescriptionDefault
observationsYes

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavioral traits on its own. It only states that it adds observations, without detailing whether observations are appended or replaced, what happens if the entity does not exist (e.g., error or auto-creation), or any other side effects. The tool is clearly a write operation, but critical safety and behavior information is missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that immediately conveys the tool's core function. There is no fluff or redundant phrasing, and the primary verb and object are front-loaded. It earns a high score for efficiency.

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 that there are no annotations and no output schema, the description must provide comprehensive context on its own. However, it only gives a high-level statement and lacks necessary details about input requirements, validation, error handling, or effect on existing data. This leaves significant gaps in the agent's understanding of the tool's full behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has zero coverage for the top-level parameter, and the description does not compensate by explaining the parameter structure. Although the nested schema properties describe entityName and contents, the description adds no semantic value beyond the schema, and the agent must rely solely on the schema to understand that observations is an array of objects with those fields. This is insufficient given the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Add' and identifies the resource 'observations' and the target 'existing entities' within the knowledge graph. This clearly distinguishes it from sibling tools like create_entities (which creates entities) and delete_observations (which removes observations), making the tool's purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies that this tool is used when adding observations to existing entities, but it does not explicitly state when to use it over alternatives or provide any comparison with sibling tools. There is no mention of constraints such as 'only for existing entities' or guidance about creating entities first. Thus, the usage context is implied rather than explicitly outlined.

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.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 states the tool creates entities, implying a write operation, but doesn't cover permissions, idempotency, error handling, or what happens on partial failures (e.g., if some entities fail). 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 front-loaded and wastes no space, making it easy 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 mutation tool with 1 parameter (an array of nested objects), no annotations, and no output schema, the description is insufficient. It doesn't explain return values, error cases, or behavioral nuances, leaving the agent with inadequate information for reliable 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 description mentions 'multiple new entities' which hints at the 'entities' array parameter, but schema description coverage is 0%, meaning all parameter details are undocumented. The description adds minimal value beyond the schema's structure, so it meets the baseline for moderate 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 ('Create multiple new entities') and the target resource ('in the knowledge graph'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'create_relations' or 'add_observations', which would require a 5.

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 'add_observations' or 'create_relations'. It lacks context about prerequisites, such as whether entities must exist before adding observations or relations, or when batch creation is preferred over individual operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_relationsB

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

ParametersJSON Schema
NameRequiredDescriptionDefault
relationsYes

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It only states 'create' and offers an active-voice guideline, but does not mention idempotency, validation of from/to entities, behavior on duplicates, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with a brief second clause. Every word earns its place and the main purpose is front-loaded.

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 or output schema, the description is too sparse. It omits critical details such as whether from/to entities must already exist, how duplicates are handled, and whether creation is atomic for the batch.

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% at the top level, so the description needed to compensate. It adds the active-voice guideline but does not explain the structure of the relations array or the meaning of from/to/relationType, which the schema already partially covers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (create), the object (multiple new relations), and the context (knowledge graph). It distinguishes from siblings like delete_relations and create_entities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for creating relations, but it does not explicitly state when to use it versus alternatives or mention any prerequisites. The active-voice guideline is a style note, not usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_entitiesA

Delete multiple entities and their associated relations from the knowledge graph

ParametersJSON Schema
NameRequiredDescriptionDefault
entityNamesYesAn array of entity names to delete

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It does disclose that associated relations are deleted as part of the operation, which is a useful behavioral detail. However, it does not mention irreversibility, permissions, or whether observations are affected, leaving gaps 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 concise sentence that front-loads the action and scope with no unnecessary words. Every word contributes to understanding the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter destructive tool with no output schema, the description conveys the core purpose but omits behavioral details such as error handling, atomicity, and return values. Given the lack of annotations, it is moderately complete but has room for improvement.

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% coverage of the parameter 'entityNames' with a description, so the baseline is 3. The tool description does not add any additional parameter semantics beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool deletes multiple entities and their associated relations, using a specific verb ('Delete') and resource ('entities' and 'relations'). It distinguishes itself from sibling tools like delete_relations, which only handle relations, and delete_observations, which handles observations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as delete_relations or delete_observations. It does not state any exclusions, prerequisites, or scenarios where another tool would be more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_observationsB

Delete specific observations from entities in the knowledge graph

ParametersJSON Schema
NameRequiredDescriptionDefault
deletionsYes

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 must disclose behavioral traits. It only states the action without mentioning permanence, side effects, required permissions, or return format. As a mutation tool, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that directly conveys the core action, with no unnecessary words. It is well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a non-trivial parameter schema and no output schema or annotations. The description is too minimal to fully inform usage, lacking details on how to specify deletions and what to expect in response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not explain the 'deletions' parameter structure. Schema coverage is 0% for the top-level parameter, and the description adds no semantic meaning beyond the schema's nested field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the function: deleting specific observations from entities in a knowledge graph. It distinguishes itself from sibling tools like delete_entities and add_observations by specifying the granularity ('specific observations').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as delete_entities or when not to use it. The description lacks any context or conditions for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_relationsA

Delete multiple relations from the knowledge graph

ParametersJSON Schema
NameRequiredDescriptionDefault
relationsYesAn array of relations to delete

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must convey behavioral traits, but it only says 'Delete' without mentioning consequences such as irreversibility, partial failure handling, or permissions. For a mutating operation, 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 sentence that is direct and front-loaded. Every word earns its place, and there is no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one well-specified parameter and no output schema, so the core purpose is covered. However, behavioral details like error handling, atomicity, or effects on related entities are absent, which leaves some ambiguity for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully describes the 'relations' parameter and its nested properties (from, to, relationType), so the description adds little beyond what is already structured. The phrase 'multiple' aligns with the array type but does not provide extra meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Delete') on a specific resource ('relations'), and the plural 'multiple relations' distinguishes this from sibling tools like delete_entities and delete_observations. It is concise and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for deleting one or more relations, but it does not explicitly state when to prefer this over alternatives, nor does it mention any exclusions or prerequisites. It provides only minimal contextual guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

open_nodesA

Open specific nodes in the knowledge graph by their names. Returns the complete node information including subdomain and all metadata.

ParametersJSON Schema
NameRequiredDescriptionDefault
namesYesAn array of entity names to retrieve, returning full entity information including subdomain

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses the behavior of returning 'complete node information including subdomain and all metadata', which adds value beyond the input schema. However, it doesn't cover error handling (e.g., invalid names), performance aspects (e.g., rate limits), or mutation effects (implied read-only but not stated). The description is adequate but misses key operational details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences: the first states the action and input, the second specifies the output. Every word earns its place with no redundancy or fluff. It's front-loaded with the core purpose and efficiently structured for quick comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 1 parameter with 100% schema coverage and no output schema, the description is moderately complete. It covers purpose and output but lacks details on errors, permissions, or performance. For a read operation with no annotations, it should ideally mention safety (non-destructive) or limitations, but it's adequate for basic use. The absence of an output schema increases the burden slightly, which isn't fully met.

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 'names' parameter fully documented in the schema as 'An array of entity names to retrieve, returning full entity information including subdomain'. The description adds marginal value by reinforcing 'by their names' and linking to the output, but doesn't provide additional syntax, constraints, or examples beyond the schema. Baseline 3 is appropriate given 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: 'Open specific nodes in the knowledge graph by their names' (verb+resource) and 'Returns the complete node information including subdomain and all metadata' (outcome). It distinguishes from siblings like 'search_nodes' (search vs. open by name) and 'read_graph' (read entire graph vs. specific nodes), though not explicitly named. However, it doesn't fully differentiate from 'search_nodes' in edge cases where names are known.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when you know exact node names ('by their names') and want complete information. It doesn't explicitly state when to use alternatives like 'search_nodes' (for fuzzy/partial matches) or 'read_graph' (for entire graph), nor does it mention prerequisites or exclusions. The context is clear but lacks explicit guidance on tool selection.

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?

With no annotations, the description must carry the full burden of behavioral disclosure, but it only states that the graph is read. It does not mention that the operation is read-only, whether it requires permissions, or that the response may be very large. The word 'read' implies non-destructive behavior, but no details are given.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that directly states the tool's purpose with no redundancy. It is well-structured and every word contributes to the meaning.

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 lack of annotations and output schema, the description should explain what reading the graph returns or any caveats (e.g., large payloads). It does not, and it also fails to differentiate this tool from search_nodes for partial reads. The tool is simple, but the description is still incomplete for an agent to use it confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema is empty, so there is nothing to document. The baseline for zero parameters is 4, and the description correctly indicates that no inputs are needed, without adding unnecessary detail.

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 uses a specific verb 'read' and identifies the resource 'the entire knowledge graph,' clearly distinguishing it from sibling tools that create or delete entities. However, it is brief and doesn't elaborate on the output format or how it differs from export_to_obsidian, so it falls short of 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 explicit guidance on when to use this tool over alternatives like search_nodes or open_nodes. It is only implied that this is for reading the whole graph, with no mention of filtering or use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_nodesA

Search for nodes in the knowledge graph based on one or more keywords. The search covers entity names, types, subdomains, and observation content. Multiple keywords are treated as OR conditions, where any keyword must match somewhere in the entity's fields.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSpace-separated keywords to match against entity fields. Any keyword must match (OR condition). Example: 'budget management' will find entities where either 'budget' or 'management' appears in any field.

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the search covers multiple fields (entity names, types, subdomains, observation content), uses OR logic for multiple keywords, and matches keywords anywhere in fields. However, it lacks details on response format, pagination, or error handling, which are important for a search 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 appropriately sized and front-loaded, with two sentences that efficiently convey purpose, scope, and behavior without redundancy. Every sentence adds value, such as specifying search fields and keyword logic, making it concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (search operation with one parameter) and no annotations or output schema, the description is moderately complete. It covers what the tool does and how keywords are handled, but lacks details on return values, limitations, or error cases, which would be helpful for an agent to use it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the 'query' parameter thoroughly. The description adds minimal value beyond the schema by reiterating the OR condition and field coverage, but does not provide additional syntax, examples, or constraints. 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('search for nodes') and resource ('knowledge graph'), and distinguishes it from siblings by specifying it searches based on keywords across multiple entity fields. It explicitly mentions what fields are searched (entity names, types, subdomains, observation content), which differentiates it from tools like 'open_nodes' or 'read_graph'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use this tool: when searching for nodes by keywords across specific entity fields. It does not explicitly state when not to use it or name alternatives among siblings, but the context is sufficient for an agent to infer this is for keyword-based searches rather than other operations like creation or deletion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 9 tool updates
    • First observedadd_observations
    • First observedcreate_entities
    • First observedcreate_relations
    • First observeddelete_entities
    • First observeddelete_observations
    • First observeddelete_relations
    • First observedopen_nodes
    • First observedread_graph
    • First observedsearch_nodes
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Scored across 9 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no ambiguity: create/delete operations target specific components (entities, relations, observations), while read/search/open handle different access patterns. The descriptions reinforce these distinctions, making misselection unlikely.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case throughout (e.g., add_observations, delete_relations, search_nodes). The naming is predictable and readable, with no deviations in style or convention.

Tool Count5/5

With 9 tools, the server is well-scoped for a knowledge graph memory system. Each tool earns its place by covering essential CRUD operations and access methods, avoiding both bloat and insufficiency for the domain.

Completeness4/5

The toolset provides strong coverage for core knowledge graph operations, including creation, deletion, reading, and searching. A minor gap exists in update capabilities for entities or observations, which agents might need to work around by deleting and recreating, but overall workflows are well-supported.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • my-memory-mcp

    moontmsai
    F
    license
    Not graded
    quality
    D
    maintenance
    A MCP server that provides persistent memory for AI assistants, storing personal information, relationships, and observations to enable personalized and contextual conversations.
    4
    -

  • CogniRepo

    ashlesh-t
    A
    license
    B
    quality
    A
    maintenance
    MCP server providing persistent memory and context for AI tools, including semantic memory, knowledge graph, and session history to avoid starting from scratch in every conversation.
    35
    14
    MIT

  • Graph-Mem MCP

    Sathvik-1007
    A
    license
    Not graded
    quality
    A
    maintenance
    A universal MCP server providing persistent, structured memory through a knowledge graph with graph storage, semantic vector search, and multi-hop traversal for AI agents and IDEs.
    1
    MIT

  • Simple Memory MCP Server

    AojdevStudio
    F
    license
    A
    quality
    D
    maintenance
    A lightweight MCP server that provides persistent knowledge graph storage for AI assistants, enabling memory across sessions through entity-relationship storage with JSON file persistence.
    10
    1
    -

Appeared in Searches