1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@xgmem Remember that Alice is a senior developer in the demo-project" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

xgmem

by meetdhanani17

Overview Schema Source Related Servers Discussions Admin

JavaScript

Hybrid

xgmem MCP Memory Server

xgmem is a TypeScript-based Model Context Protocol (MCP) server for enabling project-specific and knowledge graph-based memory for Claude, LLM agents, and other tools. It supports storing, retrieving, and managing entities, relations, and observations per project, with a focus on flexibility and cross-project knowledge sharing.

Features

Knowledge graph storage for entities, relations, and observations
CRUD operations via MCP tools
Persistence to disk (memory.json)
Docker and TypeScript support

Related MCP server: Knowledge Graph MCP Server

Use Case

xgmem is ideal for:

Agents and LLMs that need to store and retrieve structured memory (entities, relations, observations) per project.
Cross-project knowledge sharing and migration.
Scalable, disk-persistent, and queryable memory for agent ecosystems.

Usage

MCP Config Example

Add to your MCP config (e.g., for windsurf):

"mcpServers": {
    "xgmem": {
      "command": "npx",
      "args": ["-y", "xgmem@latest"]
    }
  }

Install dependencies

npm install

Build

npm run build

Run (development)

npx ts-node index.ts

Run (production)

npm start

Docker

docker build -t xgmem-mcp-server .
docker run -v $(pwd)/memories:/app/memories xgmem-mcp-server

This will persist all project memory files in the memories directory on your host.

How to Save Memory (MCP API)

To save observations (memory) for a project, call the save_project_observations tool via the MCP API:

Example JSON:

{
  "name": "save_project_observations",
  "args": {
    "projectId": "demo-project",
    "observations": [
      {
        "entityName": "Alice",
        "contents": [
          "Alice joined Acme Corp in 2021.",
          "Alice is a software engineer."
        ]
      },
      {
        "entityName": "Bob",
        "contents": [
          "Bob joined Acme Corp in 2022.",
          "Bob is a product manager."
        ]
      }
    ]
  }
}

You can use any compatible MCP client, or send this JSON via stdin if running the server directly.

Tooling and API

xgmem exposes the following tools:

save_project_observations
get_project_observations
add_graph_observations
create_entities
create_relations
delete_entities
delete_observations
delete_relations
read_graph
search_nodes
search_all_projects
open_nodes
copy_memory

See the get_help tool (if enabled) for documentation and usage examples via the MCP API.

Configuration

Set MEMORY_DIR_PATH env variable to change the memory storage directory (default: /app/memories).

License

MIT

Available Tools

14 tools

add_graph_observationsB

Add new observations to existing entities in the project knowledge graph.

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes	The project identifier
`observations`	Yes	An array of observation objects to add to graph entities.

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, description only states action. Fails to disclose behavioral traits such as whether observations are appended or overwritten, or requirements for entity existence.

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?

One concise sentence with no wasted words. Front-loaded purpose. Could be slightly more structured but effective.

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 tool with 2 params and no output schema, missing guidance on return value and behavior (e.g., error on missing entity). Adequate but with 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?

Schema coverage is 100% with parameter descriptions. Description adds 'new' and 'existing' but these are already implied. Provides minimal extra value beyond schema.

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

Purpose5/5

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

Description clearly states verb 'add' and resource 'observations to existing entities in project knowledge graph'. Distinguishes from sibling tools like create_entities and create_relations.

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 explicit guidance on when to use this tool vs alternatives like create_entities or delete_observations. Implied by name but not clarified.

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

copy_memoryA

Copy memory entities and their relations from one project to another

ParametersJSON Schema

Name	Required	Description
`sourceProjectId`	Yes	The source project identifier
`targetProjectId`	Yes	The target project identifier
`entityNames`	Yes	An array of entity names to copy

TDQS

A3.5/5.0

Behavior3/5

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

The description discloses that relations are copied along with entities, which adds behavioral context beyond the input schema. However, it does not explain what happens if entities already exist in the target, whether the operation is idempotent, or any side effects. With no annotations, the description carries the burden but provides only partial transparency.

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, concise sentence that effectively communicates the core action. It is front-loaded and to the point, though it could be slightly more structured with bullet points for clarity.

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 is no output schema and the operation involves copying entities and relations, the description is incomplete. It fails to address important aspects such as what the tool returns, behavior on conflicts, or performance implications. Sibling tools like 'create_entities' and 'delete_entities' suggest a need for clarity on how this tool integrates.

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 with descriptions for all three required parameters. The description adds no additional parameter-level meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the verb 'copy', the resource 'memory entities and their relations', and specifies the scope 'from one project to another'. It distinguishes from sibling tools like 'create_entities' (which creates new) and 'delete_entities' (which deletes).

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 a use case (copying between projects) but provides no explicit guidance on when to use this tool versus alternatives, such as when to use 'create_entities' instead. No exclusions or prerequisites are mentioned.

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

create_entitiesB

Create multiple new entities in the project knowledge graph

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes	The project identifier
`entities`	Yes	An array of entities to create

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 carries full burden but only states 'Create multiple new entities'. It fails to disclose behavioral traits like idempotency, error handling, duplicate handling, or any constraints on entity names/types.

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, concise sentence that front-loads the action. It could be slightly more informative without sacrificing brevity, but it is efficient.

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

Completeness2/5

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

Given the complexity of creating multiple entities with nested arrays, the description lacks important context such as return value, batching limits, or error behavior. No output schema exists, so the description should have provided more detail.

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 coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond what the schema provides, warranting a baseline score of 3.

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

Purpose5/5

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

The description explicitly states 'Create multiple new entities in the project knowledge graph', clearly identifying the verb (create), resource (entities), and scope (project knowledge graph). It effectively distinguishes from sibling tools like create_relations or delete_entities.

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 create_relations or add_graph_observations. There is no mention of prerequisites (e.g., project existence) or conditions under which this tool is appropriate.

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

create_relationsB

Create multiple new relations between entities in the project knowledge graph

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes	The project identifier
`relations`	Yes	An array of relations to create

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description must carry the burden. It fails to disclose behavioral traits such as whether the operation is idempotent, validation rules, error handling, or required permissions 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.

Conciseness4/5

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

Single sentence, clear and to the point. No wasted words, but could be slightly more informative without excessive length.

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?

No output schema; description does not mention return values, success indicators, or potential side effects. Incomplete for a mutation tool with no annotations.

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?

Input schema has 100% description coverage, so baseline is 3. The description adds no additional meaning beyond the schema; it just restates the tool's purpose.

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?

Description clearly states the action 'create' and the resource 'multiple new relations between entities in the project knowledge graph'. It is specific and 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 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 (e.g., create_entities for entities, or adding observations). The description does not mention contexts or exclusions.

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

delete_entitiesB

Delete multiple entities and their associated relations from the project knowledge graph

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes	The project identifier
`entityNames`	Yes	An array of entity names to delete

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description adds value by disclosing that associated relations are also deleted (cascading behavior). However, it does not mention reversibility, permissions, or other side effects, leaving gaps for an AI agent.

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 conveys the core action without unnecessary words, effectively front-loading the 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 deletion tool with no annotations or output schema, the description lacks important context such as irreversibility, confirmation requirements, or error conditions. It is too minimal for safe usage.

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 clear parameter descriptions. The tool description adds no further parameter details, meeting the baseline but not exceeding it.

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

Purpose5/5

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

The description clearly states the verb 'delete', the resource 'multiple entities', and includes the association with 'their associated relations', which distinguishes it from sibling tools like delete_relations or delete_observations.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or when-not conditions. For example, it doesn't mention if entities with relations should be deleted via this tool or if relations need to be removed first.

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 project knowledge graph

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes	The project identifier
`deletions`	Yes	An array of deletions to perform

TDQS

B3.3/5.0

Behavior2/5

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

No annotations exist. The description only says 'delete' without disclosing permanence, side effects, or any constraints. For a destructive operation, more transparency is needed.

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?

Extremely concise: one 8-word sentence that is front-loaded and wastes no words.

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

Completeness3/5

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

While the core purpose is clear, the description lacks details on outcome (e.g., permanent removal) or error handling. Adequate for a simple delete but could be improved.

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 covers 100% of parameters with descriptions. The tool description adds no additional meaning beyond what's in the schema.

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

Purpose5/5

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

The description clearly states the tool deletes specific observations from entities. It distinguishes from siblings like 'delete_entities' and 'delete_relations' by specifying '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 usage guidelines provided; no mention of when to use vs alternatives (e.g., 'add_graph_observations' to add, or 'delete_entities' to remove entire entities).

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

delete_relationsB

Delete multiple relations from the project knowledge graph

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes	The project identifier
`relations`	Yes	An array of relations to delete

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only states 'delete' with no disclosure of permanence, reversibility, or side effects. Minimal behavioral 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?

Single sentence with 9 words, highly concise. Lacks structure but efficient for the given 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?

No output schema, no annotations. Description is too brief for a delete operation; missing details on success criteria, error handling, and behavioral expectations.

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 coverage is 100% with clear descriptions for all parameters. Description does not add additional meaning beyond schema, so baseline 3 is appropriate.

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

Purpose5/5

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

Description clearly states verb 'Delete', resource 'relations', and context 'from the project knowledge graph'. Distinguishes from sibling tools like create_relations and delete_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?

Implies usage for deleting multiple relations from a project, but provides no explicit guidance on when to use versus alternatives like delete_entities or when not to use.

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

get_project_observationsB

Get all observations saved in the separate file for a given projectId.

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes	The project identifier

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so the description carries the full burden. It does not disclose read-only nature, potential errors, side effects, or authentication requirements. The phrase 'separate file' is ambiguous and lacks behavioral 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 very short and to the point, with no wasted words. However, it is not front-loaded with critical details; it could benefit from a slightly more structured format.

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 simplicity of the tool (one parameter, no output schema), the description covers the basic purpose. However, it omits details about return format, error handling, or what exactly 'observations' are, leaving some 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?

Schema coverage is 100% for the single parameter projectId, which already includes a description. The description adds the context 'separate file' but does not provide significant additional meaning beyond what the schema offers.

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 (Get), the resource (observations), and the context (saved in a separate file for a given projectId). It effectively distinguishes this tool from siblings like save_project_observations and add_graph_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 explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, limitations, or conditions under which this tool should be chosen over others.

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

list_projectsB

List all projects with stored memory

ParametersJSON Schema

Name	Required	Description	Default
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 carries full burden but only states basic purpose. It does not disclose if the operation is read-only, whether pagination exists, or any other behavioral 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?

A single sentence that is perfectly concise with no extraneous words. It front-loads the action and resource.

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 no output schema, no annotations, and no parameters, the description should explain the meaning of 'projects' and 'stored memory' and indicate the output format. It does not, leaving significant gaps for an AI agent.

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 schema description coverage is 100%. The description adds no param info, which is acceptable as there are none to describe. Baseline score of 4 applies.

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

Purpose4/5

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

The description clearly states the verb 'list' and resource 'projects', and adds context about 'stored memory'. It implicitly distinguishes from 'search_all_projects' which likely involves filtering, but the description does not explicitly differentiate.

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 like 'search_all_projects'. There is no mention of use cases, prerequisites, or exclusions.

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

open_nodesB

Open specific nodes in a project's knowledge graph by their names

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes	The project identifier
`names`	Yes	An array of entity names to retrieve

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description must cover behavioral traits. 'Open' is ambiguous—does it retrieve data or mutate UI state? No mention of side effects, read-only nature, or what happens to existing state. This lack of transparency could lead to misinterpretation.

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?

Single sentence of 12 words conveys core purpose efficiently. Front-loaded with key action and resource. Could be slightly longer to clarify 'open', but as-is it is concise without unnecessary filler.

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?

Without output schema or annotations, description is too brief. Does not explain return value, side effects, or how it differs from similar tools. In a domain with many sibling tools, more context is needed for correct invocation.

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

Parameters3/5

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

Schema covers both parameters with descriptions (100% coverage). The tool description adds minimal extra meaning ('by their names' confirms 'names' parameter but doesn't clarify if they are display names or IDs). With full schema coverage, baseline 3 is appropriate as description does not significantly enhance 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 the tool 'open specific nodes in a project's knowledge graph by their names', using a specific verb ('open'), resource ('nodes in project knowledge graph'), and method ('by names'). This distinguishes it from siblings like 'search_nodes' which search rather than open.

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 vs alternatives (e.g., search_nodes, read_graph). The description does not mention prerequisites, context, or exclusion criteria. The user must infer usage from the name alone.

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

read_graphA

Read the entire knowledge graph for a specific project

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes	The project identifier

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It indicates a read-only operation but lacks details about the response format, performance impact, or what 'entire knowledge graph' includes (nodes, relations, observations?). Some transparency but incomplete.

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?

Single sentence, no wasted words, appropriately sized for a simple tool with one parameter.

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

Completeness3/5

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

For a tool that reads the entire graph, the description is terse. It omits details about the output (e.g., does it return nodes, edges, observations?) and potential size implications. With no output schema, more context would be beneficial.

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 coverage is 100% with projectId described as 'The project identifier.' Description reinforces the need for a project but adds no additional meaning beyond the schema. Baseline 3 applies.

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

Purpose5/5

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

The description clearly states the tool reads the entire knowledge graph for a specific project, using a specific verb ('Read') and resource ('knowledge graph'). It distinguishes itself from sibling tools that add, copy, create, or delete entities.

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

Usage Guidelines4/5

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

The description implies the tool is for reading the whole graph when given a project ID, but does not explicitly state when to use it versus alternatives like search_nodes or get_project_observations. No exclusions or when-not-to-use guidance provided.

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

save_project_observationsB

Save observations for a project to a separate file in the format { projectId, observations: [{ entityName, contents: [...] }] }.

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes	The project identifier
`observations`	Yes	An array of observation objects to add

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, and the description fails to disclose key behaviors such as whether the file is overwritten or appended, where it is saved, permission requirements, or error handling. Only mentions the output format.

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?

Single sentence with no unnecessary words, directly stating the purpose and format.

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?

No output schema, and the description does not explain what happens after saving (e.g., return value, success indicator). For a mutation tool, this is insufficient coverage.

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 coverage is 100%, so baseline is 3. The description reiterates the schema structure without adding new meaning, earning the baseline score.

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 'save observations for a project' and specifies the output format, distinguishing it from siblings like 'add_graph_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 like 'add_graph_observations' or 'get_project_observations'. The description only states what it does without contextual usage hints.

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

search_all_projectsB

Search for nodes across all projects' knowledge graphs based on a query

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	The search query to match against entity names, types, and observation content

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided; the description only states basic functionality without disclosing behavioral traits like scope limitations, performance, or output format.

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?

Single sentence, 11 words, no wasted information. Efficiently communicates the core 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?

No output schema; description omits what the tool returns (e.g., node IDs, details) and does not clarify whether 'all projects' means user-accessible or all on the server. Incomplete for a search tool.

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

Parameters3/5

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

100% schema description coverage for the single parameter 'query' already explains its purpose. The description adds no additional meaning beyond the schema.

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

Purpose5/5

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

The description clearly states the verb 'search', the resource 'nodes across all projects' knowledge graphs', and the basis 'query'. It distinguishes from siblings like 'search_nodes' which likely operates on a single project.

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 like 'search_nodes'. No mention of when not to use it or prerequisites.

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

search_nodesB

Search for nodes in a specific project's knowledge graph based on a query

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes	The project identifier
`query`	Yes	The search query to match against entity names, types, and observation content

TDQS

B3.3/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 fully convey behavioral traits. It states the search matches against entity names, types, and observation content, but omits details like whether results are paginated, what is returned (IDs vs full objects), or if the operation is read-only.

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 sentence of 14 words, concise and to the point. However, it could be slightly more informative without adding length.

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 no output schema, so the description should clarify what is returned (e.g., list of nodes with certain fields). It only says 'search for nodes', leaving the return format and limitations unclear. For a search tool, pagination and result ordering are also missing.

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

Parameters3/5

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

Schema description coverage is 100%, and the description does not add meaning beyond the schema's property descriptions. The tool description only says 'based on a query', which is already implied by the schema. Baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool searches for nodes in a project's knowledge graph based on a query, using a specific verb and resource. It distinguishes from siblings like search_all_projects (which searches all projects) and read_graph (which reads the whole graph).

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 searching within a specific project, but lacks explicit guidance on when to use this tool versus alternatives (e.g., search_all_projects). No exclusions or prerequisites are mentioned.

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.

14 tool updatesv0.0.1May 17, 2026
- First observedadd_graph_observations
- First observedcopy_memory
- First observedcreate_entities
- First observedcreate_relations
- First observeddelete_entities
- First observeddelete_observations
- First observeddelete_relations
- First observedget_project_observations
- First observedlist_projects
- First observedopen_nodes
- First observedread_graph
- First observedsave_project_observations
- First observedsearch_all_projects
- First observedsearch_nodes

Deploy Server

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

TDQS

A3.5/5.0

Scored 2026-05-17 03:35 across 14 tools

Disambiguation5/5

Each tool has a distinct purpose: CRUD for entities, relations, observations, plus project management and search. No significant overlap.

Naming Consistency4/5

Mostly snake_case verb_noun pattern consistent. Minor deviations like 'open_nodes' vs 'get_project_observations' and 'copy_memory' instead of 'copy_entities'.

Tool Count5/5

14 tools is well-scoped for a knowledge graph memory system, covering essential operations without excess.

Completeness3/5

Covers create, delete, read, and search, but missing update operations for entities, relations, and observations. No project deletion either.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Motecloud MemoryOAuth
io.github.motecloud
Cloud-hosted MCP server for durable AI memory
Knowledge & Memory Cloud Platforms
2
XMemo AOAuth
io.github.yonro
Shared, governed long-term memory for AI agents across tools and sessions via MCP and REST.
Autonomous Agents Knowledge & Memory
31212
Living MemoryOAuth
to.viibe
An MCP memory server. One memory your agents share — across models, devices and apps.
Knowledge & Memory Autonomous Agents AI & Machine Learning
22
agent-memory A
io.github.lazymac2x
Cloudflare Workers MCP server: agent-memory
Knowledge & Memory Cloud Platforms
52

Related MCP Servers

MCP Docs RAG Server
RAG Systems Developer Tools File Systems
kazuph
F
license
A
quality
F
maintenance
A TypeScript MCP server that allows querying documents using LLMs with context from locally stored repositories and text files through a RAG (Retrieval-Augmented Generation) system.
Updated 2 years ago (2025-03-10 21:55 UTC)
4
17
-
Knowledge Graph MCP Server
Knowledge & Memory RAG Systems Databases
YUChoe
F
license
Not graded
quality
D
maintenance
A TypeScript MCP server for managing persistent knowledge graphs with entities, directional relations, and time-based observations. It enables users to create, search, and track structured information with built-in concurrency control and JSON file storage.
Updated 5 months ago (2026-03-30 04:28 UTC)
-
dragon-brain
Knowledge & Memory Vector Databases Search
iikarus
A
license
Not graded
quality
A
maintenance
Open-source MCP server that gives any LLM long-term memory using a knowledge graph and vector search hybrid. It stores entities, observations, and relationships, enabling semantic recall across sessions with automatic clustering and fail-loud infrastructure.
Updated 21 days ago (2026-08-22 13:02 UTC)
50
MIT
Graph-Mem MCP
Knowledge & Memory RAG Systems
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.
Updated 2 months ago (2026-07-21 20:43 UTC)
1
MIT