The Memory Custom server enables the creation and management of a knowledge graph for LLM interactions with these capabilities:
Create and Manage Entities: Add new nodes to the knowledge graph
Establish Relations: Define connections between entities
Add Observations: Append facts or attributes to existing entities
Delete Data: Remove entities, observations, or relations
Set Memory Paths: Customize file paths for storing memory data
Search and Retrieve: Find nodes based on queries or access specific nodes by name
Read Entire Graph: Access the complete knowledge graph structure
Timestamping: Automatically track when changes occur
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Memory Custom add my meeting with Alex about the Q3 project to memory"
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.
This project adds new features to the Memory server offered by the MCP team. It allows for the creation and management of a knowledge graph that captures interactions via a language model (LLM).
Users can now specify different memory file paths for various projects.
Why?: This feature enhances organization and management of memory data, allowing for project-specific memory storage.
The server now generates timestamps for interactions.
Why?: Timestamps enable tracking of when each memory was created or modified, providing better context and history for the stored data.
Related MCP server: KG Memory
Node.js (version 16 or higher)
To install Knowledge Graph Memory Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @BRO3886/mcp-memory-custom --client claudeClone the repository:
git clone git@github.com:BRO3886/mcp-memory-custom.git
cd mcp-memory-customInstall the dependencies:
npm installBefore running the server, you can set the MEMORY_FILE_PATH environment variable to specify the path for the memory file. If not set, the server will default to using memory.json in the same directory as the script.
Add this to your claude_desktop_config.json / .cursor/mcp.json file:
{
"mcpServers": {
"memory": {
"command": "node",
"args": ["/path/to/mcp-memory-custom/dist/index.js"]
}
}
}System Prompt changes:
Follow these steps for each interaction:
1. The memoryFilePath for this project is /path/to/memory/project_name.json - always pass this path to the memory file operations (when creating entities, relations, or retrieving memory etc.)
2. User Identification:
- You should assume that you are interacting with default_user
- If you have not identified default_user, proactively try to do so.
3. 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"
4. 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)
5. 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, add timestamps to wherever required. You can get current timestamp via get_current_time
b) Connect them to the current entities using relations
c) Store facts about them as observations, add timestamps to observations via get_current_time
IMPORTANT: Provide a helpful and engaging response, asking relevant questions to encourage user engagement. Update the memory during the interaction, if required, based on the new information gathered (point 4).To start the Knowledge Graph Memory Server, run:
npm run build
node dist/index.jsThe server will listen for requests via standard input/output.
The server exposes several tools that can be called with specific parameters:
Get Current Time
Set Memory File Path
Create Entities
Create Relations
Add Observations
Delete Entities
Delete Observations
Delete Relations
Read Graph
Search Nodes
Open Nodes
Inspired by the Memory server from Anthropic.
Add new observations to existing entities in the knowledge graph
| Name | Required | Description | Default |
|---|---|---|---|
| observations | Yes | ||
| memoryFilePath | Yes | The path to the memory file |
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 adds observations but does not cover critical aspects such as whether this is a mutation (implied by 'Add'), potential side effects (e.g., overwriting existing observations), authentication needs, error handling, or rate limits. This is inadequate for a tool that modifies data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 appropriately sized, 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.
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 incomplete parameter coverage (50%), the description is insufficient. It fails to address behavioral traits, return values, or detailed usage scenarios, leaving the agent with significant gaps in understanding how to invoke and interpret results from this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with 'observations' and 'memoryFilePath' documented in the schema but lacking details in the description. The description adds minimal value by hinting at the purpose ('Add new observations to existing entities'), but does not elaborate on parameter semantics beyond what the schema provides, such as format expectations for 'entityName' or 'memoryFilePath'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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'), distinguishing it from siblings like 'create_entities' or 'delete_observations' by focusing on updating existing entities. However, it lacks specificity about what 'observations' entail (e.g., text notes, metadata), which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding observations to existing entities but provides no explicit guidance on when to use this tool versus alternatives like 'create_entities' or 'delete_observations', nor does it mention prerequisites (e.g., entities must already exist). This leaves gaps in contextual decision-making for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create multiple new entities in the knowledge graph
| Name | Required | Description | Default |
|---|---|---|---|
| entities | Yes | ||
| memoryFilePath | Yes | The path to the memory file |
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 indicates a write operation ('create') but doesn't mention permissions, side effects, error handling, or response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 easy to parse quickly. Every word earns its place without being overly brief or verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 incomplete parameter documentation (50% coverage), the description is inadequate. It should explain more about the creation process, expected outcomes, or error conditions to help an agent use it correctly, given the complexity implied by batch entity creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with the 'entities' parameter well-documented in the schema but 'memoryFilePath' lacking description. The tool description adds no parameter-specific information beyond what's implied by the name ('create multiple new entities'), so it doesn't compensate for the coverage gap. Baseline 3 is appropriate as the schema handles half the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 provides a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'create_relations' or 'add_observations' beyond the basic resource difference, preventing 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.
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', nor does it mention prerequisites, constraints, or typical scenarios for batch creation. It merely states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create multiple new relations between entities in the knowledge graph. Relations should be in active voice
| Name | Required | Description | Default |
|---|---|---|---|
| relations | Yes | ||
| memoryFilePath | Yes | The path to the memory file |
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 creates relations, implying a write operation, but doesn't cover permissions, side effects, error handling, or response format. The 'active voice' note is trivial and doesn't add meaningful behavioral insight, leaving 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.
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. However, the 'active voice' note is somewhat redundant and doesn't add value, slightly detracting from perfect conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, 50% schema coverage, and no output schema, the description is insufficient. It lacks details on behavioral traits, error cases, and return values, making it incomplete for safe and effective agent use in a knowledge graph context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with the 'relations' parameter well-documented but 'memoryFilePath' lacking context. The description doesn't add any parameter-specific details beyond what the schema provides, such as explaining the structure of relations or the purpose of the memory file. Since schema coverage is moderate, the baseline score of 3 is appropriate, as the description doesn't compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 relations') and the resource ('between entities in the knowledge graph'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'delete_relations' or 'create_entities', and the 'active voice' note is stylistic rather than functional, so it doesn't reach the highest clarity level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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', nor does it mention prerequisites or context for usage. It's purely functional without any operational context, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete multiple entities and their associated relations from the knowledge graph
| Name | Required | Description | Default |
|---|---|---|---|
| entityNames | Yes | An array of entity names to delete | |
| memoryFilePath | Yes | The path to the memory file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the deletion action without disclosing critical behavioral traits. It doesn't mention if deletion is permanent, requires specific permissions, affects related data beyond relations, or has rate limits. The phrase 'and their associated relations' adds some context but is insufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the action, scope, and resource without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a destructive mutation with no annotations and no output schema, the description is incomplete. It lacks details on behavior, error handling, return values, or safety considerations, leaving significant gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both parameters fully. The description adds no additional meaning beyond implying 'entityNames' refers to entities in a knowledge graph, which is redundant with the schema. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete multiple entities and their associated relations') and the resource ('from the knowledge graph'), making the purpose unambiguous. It distinguishes from siblings like 'delete_observations' and 'delete_relations' by specifying entities and their relations, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'delete_observations' or 'delete_relations', nor does it mention prerequisites such as needing existing entities. The description implies usage for bulk deletion but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete specific observations from entities in the knowledge graph
| Name | Required | Description | Default |
|---|---|---|---|
| deletions | Yes | ||
| memoryFilePath | Yes | The path to the memory file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool deletes observations, implying a destructive mutation, but doesn't specify if deletions are permanent, require specific permissions, or have side effects like cascading changes. This leaves critical behavioral traits undocumented for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and target without unnecessary words. Every part earns its place by concisely conveying the tool's purpose, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a destructive mutation with no annotations, no output schema, and incomplete parameter documentation (50% coverage), the description is insufficient. It lacks details on behavior, return values, error handling, or how it integrates with sibling tools, leaving gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with parameters 'deletions' and 'memoryFilePath' documented in the schema but not in the description. The description doesn't add meaning beyond the schema, such as explaining what 'observations' entail or how 'memoryFilePath' relates to the knowledge graph. Baseline 3 is appropriate as the schema provides some coverage without description enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this from sibling tools like 'delete_entities' or 'delete_relations', which would require mentioning it only removes observations rather than entire entities or relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like needing existing entities or observations, nor does it compare to siblings such as 'delete_entities' for broader deletions or 'add_observations' for additions, leaving the agent without contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete multiple relations from the knowledge graph
| Name | Required | Description | Default |
|---|---|---|---|
| relations | Yes | An array of relations to delete | |
| memoryFilePath | Yes | The path to the memory file |
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 deletes relations, implying a destructive mutation, but fails to mention critical aspects like required permissions, whether deletions are reversible, error handling for non-existent relations, or batch operation limits. This leaves significant behavioral gaps for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 any fluff or redundancy. It's 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.
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 inadequate. It lacks essential context such as what happens after deletion (e.g., confirmation, error messages), side effects on the knowledge graph, or dependencies like required file formats for 'memoryFilePath'. This leaves the agent with insufficient information for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear documentation for both parameters ('relations' and 'memoryFilePath'). The description doesn't add any meaningful parameter semantics beyond what's already in the schema, such as format examples or constraints, so it meets the baseline for high schema coverage without providing extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('multiple relations from the knowledge graph'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate this tool 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.
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'. There's no mention of prerequisites, context, or exclusions, leaving the agent with minimal usage direction beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current time
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Get the current time' implies a read-only operation, but it doesn't specify what time format is returned, whether it's server time or system time, if there are rate limits, or any authentication requirements. This leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise at three words, front-loaded with the core action, and has zero wasted sentences. Every word earns its place by directly stating the tool's function without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. However, it lacks context about the returned time format or timezone, which would be helpful for an agent to understand what to expect. Without output schema, some return value guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to add parameter information, and it appropriately doesn't mention any. The baseline for 0 parameters is 4, as it avoids unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('Get') and resource ('current time'), making it immediately understandable. However, it doesn't differentiate from sibling tools, which include various CRUD operations on different resources, 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.
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 sibling tools like 'read_graph' or 'search_nodes' that might involve time-related queries, there's no indication of when this simple time-fetching tool is preferred over more complex options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open specific nodes in the knowledge graph by their names
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | An array of entity names to retrieve | |
| memoryFilePath | Yes | The path to the memory file |
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 'opens' nodes, which suggests a read operation, but doesn't clarify if this is a safe read, what permissions are needed, whether it modifies state, or what the output format might be. The description lacks critical behavioral context for a tool interacting with 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's appropriately sized and front-loaded with the core purpose, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a knowledge graph tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'opening' nodes entails (e.g., retrieving details, expanding views), what data is returned, or how it differs from sibling tools. For a tool with two required parameters and potential behavioral nuances, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both parameters ('names' and 'memoryFilePath') adequately. The description adds no additional meaning beyond implying that 'names' refer to entity names in the knowledge graph, which is minimal value over the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('open') and target resource ('specific nodes in the knowledge graph by their names'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'read_graph' or 'search_nodes', which might have overlapping functionality for accessing graph data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'read_graph' or 'search_nodes'. It mentions opening nodes 'by their names', which implies a prerequisite of knowing exact names, but doesn't explicitly state this or compare to other tools for different access patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the entire knowledge graph
| Name | Required | Description | Default |
|---|---|---|---|
| memoryFilePath | Yes | The path to the memory file |
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 address critical aspects like performance implications of reading 'entire' graphs, potential memory issues, authentication needs, error conditions, or return format. For a tool with no annotation coverage, this is a significant gap in 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single four-word sentence that's front-loaded with the core action. There's zero wasted language, and it efficiently communicates the basic purpose without unnecessary elaboration. This represents ideal conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent complexity (reading 'entire' knowledge graphs), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'reading' entails (e.g., returns structure, format, size limitations), doesn't address performance or memory concerns, and provides no context about the relationship between the memory file and the graph. For a potentially resource-intensive operation, this leaves too many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'memoryFilePath' well-documented in the schema. The description adds no parameter-specific information beyond what the schema provides—it doesn't explain what a 'memory file' is, how it relates to the knowledge graph, or provide context about the file path format. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read the entire knowledge graph' clearly states the verb ('Read') and resource ('knowledge graph'), but it's vague about scope and specificity. It doesn't distinguish from sibling tools like 'search_nodes' or 'open_nodes', which also likely read graph data. The phrase 'entire' adds some scope but remains ambiguous about what constitutes 'entire' versus partial reads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With siblings like 'search_nodes' and 'open_nodes' that likely read graph data in different ways, the description offers no context on usage scenarios, prerequisites, or exclusions. This leaves the agent guessing about the appropriate context for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for nodes in the knowledge graph based on a query
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query to match against entity names, types, and observation content | |
| memoryFilePath | Yes | The path to the memory file |
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 based on a query but does not describe key behaviors: whether it returns partial matches, supports pagination, has rate limits, requires authentication, or what the output format is (e.g., list of nodes with details). For a search tool 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.
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 with the core action ('Search for nodes'), making it easy to parse. Every part of the sentence earns its place by specifying the resource and context, though it could benefit from more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (searching a knowledge graph with 2 required parameters) and the lack of annotations and output schema, the description is incomplete. It does not explain what 'nodes' include, how results are returned, or any behavioral traits like search scope or limitations. For a tool with no structured output information, the description should provide more context to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('query' and 'memoryFilePath'). The description adds no additional meaning beyond the schema, such as query syntax examples or memory file path constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Search for nodes in the knowledge graph based on a query', which specifies the verb ('search'), resource ('nodes'), and scope ('knowledge graph'). It distinguishes from siblings like 'open_nodes' (likely for opening specific nodes) and 'read_graph' (likely for reading the entire graph), though not explicitly. However, it could be more specific about what 'nodes' encompass (e.g., entities, relations, observations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 sibling tools like 'open_nodes' (which might retrieve specific nodes) or 'read_graph' (which might fetch the entire graph), nor does it specify prerequisites (e.g., needing a memory file path). Without such context, an agent might struggle to choose between this and other tools for accessing graph data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes focused on knowledge graph operations, but 'open_nodes' and 'search_nodes' could be confused as both involve accessing nodes. The descriptions clarify that 'open_nodes' retrieves specific nodes by name while 'search_nodes' queries based on content, but the overlap in node retrieval might cause misselection.
Tools follow a consistent verb_noun pattern (e.g., add_observations, create_entities) with minor deviations. 'get_current_time' uses 'get' instead of a more domain-specific verb, and 'open_nodes' uses 'open' which is less common in this context, but overall the naming is readable and mostly predictable.
With 10 tools, the count is well-scoped for managing a knowledge graph, covering creation, deletion, reading, and search operations. Each tool earns its place by addressing specific aspects of entity, relation, and observation handling, without feeling excessive or insufficient.
The tool set provides good coverage for knowledge graph CRUD operations, including create, read, and delete for entities, relations, and observations. A minor gap is the lack of update tools (e.g., update_entities or update_relations), which agents might need to work around by deleting and recreating, but core workflows are supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP memory server. One memory your agents share — across models, devices and apps.
Personal knowledge graph as an AI memory layer over MCP - read, save, and link your memories.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BRO3886/mcp-memory-custom'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
