Provides memory-focused tools for storing, retrieving, and connecting information in a Neo4j graph database, enabling AI agents to create persistent memories with semantic relationships, perform natural language searches, and build knowledge networks with flexible labeling and temporal tracking.
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., "@Neo4j Agent Memory MCP Server search for memories about project deadlines and team members"
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.
A specialized MCP server that bridges Neo4j graph database with AI agents, providing memory-focused tools for storing, recalling, and connecting information in a knowledge graph.
You can run this MCP server directly using npx:
npx @knowall-ai/mcp-neo4j-agent-memoryOr add it to your Claude Desktop configuration:
{
"mcpServers": {
"neo4j-memory": {
"command": "npx",
"args": ["@knowall-ai/mcp-neo4j-agent-memory"],
"env": {
"NEO4J_URI": "bolt://localhost:7687",
"NEO4J_USERNAME": "neo4j",
"NEO4J_PASSWORD": "your-password",
"NEO4J_DATABASE": "neo4j"
}
}
}
}Related MCP server: Neo4j Memory Server
🧠 Persistent Memory Storage - Store and retrieve memories across conversations
🔗 Semantic Relationships - Create meaningful connections between memories (KNOWS, WORKS_AT, CREATED, etc.)
🔍 Intelligent Search - Natural language search across all memory properties and relationships
🏷️ Flexible Labeling - Use any label for memories (person, place, project, idea, etc.)
⏰ Temporal Tracking - Automatic timestamps and date-based queries
🌐 Graph Exploration - Traverse relationships to discover connected information
🎯 Context-Aware - Search with depth to include related memories
🔧 LLM-Optimized - Simple tools that let the AI handle the complexity
🏢 Enterprise Ready - Supports multiple Neo4j databases
📚 Built-in Guidance - Get help on best practices and usage patterns
Unlike traditional approaches that embed complex logic in tools, this server provides simple, atomic operations and lets the LLM handle all the intelligence:
No hidden logic: Tools do exactly what they say - no auto-disambiguation or smart matching
LLM decides everything: Entity recognition, relationship inference, and conflict resolution
Transparent operations: Every action is explicit and predictable
Maximum flexibility: The LLM can implement any strategy without tool limitations
The search_memories tool uses word tokenization:
Query "John Smith" finds memories containing "John" OR "Smith"
This returns more results, letting the LLM pick the most relevant
Better than exact substring matching for names and multi-word queries
This approach makes the system more powerful and adaptable, as improvements in LLM capabilities directly translate to better memory management.
This server now supports connecting to specific databases in Neo4j Enterprise Edition. By default, it connects to the "neo4j" database, but you can specify a different database using the NEO4J_DATABASE environment variable.
search_memories: Search and retrieve memories from the knowledge graph
Word-based search: Searches for ANY word in your query (e.g., "Ben Weeks" finds memories containing "Ben" OR "Weeks")
Natural language search across all memory properties (or leave empty to get all)
Filter by memory type (person, place, project, etc.)
Filter by date with since_date parameter (ISO format)
Control relationship depth and result limits
Sort by any field (created_at, name, etc.)
create_memory: Create a new memory in the knowledge graph
Flexible type system - use any label in lowercase (person, place, project, skill, etc.)
Store any properties as key-value pairs
Automatic timestamps for temporal tracking
create_connection: Create relationships between memories
Link memories using semantic relationship types (KNOWS, WORKS_AT, LIVES_IN, etc.)
Add properties to relationships (since, role, status, etc.)
Build complex knowledge networks
update_memory: Update properties of existing memories
Add or modify any property
Set properties to null to remove them
update_connection: Update relationship properties
Modify relationship metadata
Track changes over time
delete_memory: Remove memories and all their connections
Use with caution - permanent deletion
Automatically removes all relationships
delete_connection: Remove specific relationships
Precise relationship removal
Keeps the memories intact
list_memory_labels: List all unique memory labels in use
Shows all labels with counts
Helps maintain consistency
Prevents duplicate label variations
get_guidance: Get help on using the memory tools effectively
Topics: labels, relationships, best-practices, examples
Returns comprehensive guidance for LLMs
Use when uncertain about label/relationship naming
Neo4j Database (v4.4+ or v5.x)
Install Neo4j Community or Enterprise Edition
Download from neo4j.com/download
Or use Docker: docker run -p 7474:7474 -p 7687:7687 -e NEO4J_AUTH=neo4j/password neo4j
Node.js (v18 or higher)
Required to run the MCP server
Download from nodejs.org
Claude Desktop (for MCP integration)
Download from claude.ai/download
To install Neo4j Agent Memory MCP Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @knowall-ai/mcp-neo4j-agent-memory --client claudeClone the repository:
git clone https://github.com/KnowAll-AI/mcp-neo4j-agent-memory.git
cd mcp-neo4j-agent-memoryInstall dependencies:
npm installBuild the project:
npm run buildThe server requires the following environment variables:
NEO4J_URI: Neo4j database URI (required, e.g., bolt://localhost:7687)
NEO4J_USERNAME: Neo4j username (required)
NEO4J_PASSWORD: Neo4j password (required)
NEO4J_DATABASE: Neo4j database name (optional) - For Neo4j Enterprise with multiple databases
Copy .env.example to .env and update with your credentials:
cp .env.example .env
# Edit .env with your Neo4j credentialsAdd the environment variables to your Claude Desktop configuration (see Quick Start above).
The LLM handles all the complexity of deciding what to store and how to connect memories:
User: "Remember that John works at Google as a software engineer"
Assistant: I'll remember that John works at Google as a software engineer.
[Behind the scenes, the LLM does:
1. search_memories({"query": "John"}) - Check if John exists
2. search_memories({"query": "Google"}) - Check if Google exists
3. create_memory({"label": "Person", "properties": {"name": "John", "occupation": "software engineer"}})
4. create_memory({"label": "Organization", "properties": {"name": "Google"}})
5. create_connection({"fromMemoryId": 123, "toMemoryId": 456, "type": "WORKS_AT"})]
User: "Remember that Sarah is John's manager and she started in 2019"
Assistant: I'll add that information about Sarah.
[The LLM searches for John, creates Sarah, and connects them with a MANAGES relationship including the start date]User: "Who works at Google?"
Assistant: Let me search for people who work at Google.
[LLM uses: search_memories({"query": "Google", "depth": 2})]
Based on my memory:
- John - Software Engineer at Google
- Sarah - Manager at Google (manages John, started 2019)
User: "What do you remember about John?"
Assistant: Here's what I know about John:
[LLM uses: search_memories({"query": "John", "depth": 2})]
- Works at Google as a Software Engineer
- Sarah is his manager
- [Any other connected memories found in the search]User: "John and Sarah are working on Project Atlas together"
Assistant: I'll connect John and Sarah to Project Atlas.
[The LLM:
1. Searches for John and Sarah to get their IDs
2. Creates Project Atlas: create_memory({"label": "Project", "properties": {"name": "Project Atlas"}})
3. Connects them: create_connection({"fromMemoryId": johnId, "toMemoryId": projectId, "type": "WORKS_ON"})
4. create_connection({"fromMemoryId": sarahId, "toMemoryId": projectId, "type": "WORKS_ON"})]For Neo4j Enterprise users with multiple databases, you can specify which database to connect to:
{
"env": {
"NEO4J_URI": "bolt://localhost:7687",
"NEO4J_USERNAME": "neo4j",
"NEO4J_PASSWORD": "your-password",
"NEO4J_DATABASE": "myCustomDatabase"
}
}This will connect to "myCustomDatabase" instead of the default "neo4j" database.
User: "Show me all employees in the Sales department"
Assistant: Let me search for employees in the Sales department.
[LLM uses: search_memories({"query": "Sales department", "depth": 2})]
I found these employees in the Sales department:
- John Smith (Sales Manager)
- Sarah Johnson (Sales Representative)
- Mike Brown (Account Executive)User: "Create a product called 'Premium Coffee' with price $24.99"
Assistant: I'll create that product for you.
[LLM uses: create_memory({"label": "Product", "properties": {"name": "Premium Coffee", "price": 24.99}})]
Created Premium Coffee product with ID: 456User: "The Premium Coffee uses beans from our Colombian Supplier"
Assistant: I'll connect Premium Coffee to the Colombian Supplier.
[LLM:
1. search_memories({"query": "Premium Coffee"})
2. search_memories({"query": "Colombian Supplier"})
3. create_connection({"fromMemoryId": 456, "toMemoryId": 789, "type": "SUPPLIED_BY"})]
Connected Premium Coffee to Colombian SupplierThe LLM can handle complex queries by intelligently using the search tools:
User: "Find Ben Weeks"
Assistant: I'll search for memories containing "Ben" or "Weeks".
[LLM uses: search_memories({"query": "Ben Weeks"})]
I found several people matching your search:
- Ben Weeks - Software Engineer at TechCorp (exact match)
- Sarah Ben - Data Scientist at DataCo (contains "Ben")
- John Weeks - Project Manager (contains "Weeks")
The most likely match appears to be Ben Weeks, the Software Engineer.Note: The search finds ANY word from your query, allowing the LLM to present all potentially relevant results and identify the best match based on context.
User: "What new people have I met in the last week?"
Assistant: I'll search for people added to your memory in the last 7 days.
[LLM calculates the date 7 days ago and uses:
search_memories({
"query": "",
"label": "person",
"since_date": "2024-01-20T00:00:00Z",
"order_by": "created_at DESC"
})]
Here are the new people you've met in the last week:
- Sarah Chen - Met at tech conference on Monday
- Dr. Michael Roberts - New physician, first appointment Tuesday
- Emma Wilson - Joined your project team on Wednesday
- James Park - Coffee meeting about potential collaboration ThursdayUser: "What does John do?"
Assistant: I found multiple people named John. Let me show you what I know:
[LLM uses: search_memories({"query": "John", "type": "Person", "depth": 1})]
1. John Doe - Software Engineer at Google
2. John Smith - Sales Manager in Sales Department
3. John Brown - Project Manager on Project Atlas
Which John were you asking about?User: "What events did I attend last month?"
Assistant: I'll search for event memories and check their dates.
[LLM uses: search_memories({"query": "", "label": "event", "sort_by": "created_at", "sort_order": "desc"})]
[Filters results to last month based on created_at or date properties]
Here are the events you attended last month:
- Tech Innovation Summit (March 5-6) - Keynote speaker
- Team Building Workshop (March 12) - With engineering team
- Client Dinner Meeting (March 18) - Project kickoff with ABC Corp
- WebDev Conference (March 25-27) - Attended 5 sessions on ReactThe system doesn't enforce strict types - you can create any type of memory that makes sense:
Common Types (lowercase): person, place, organization, project, event, topic, object, animal, plant, food, activity, media, skill, document, meeting, task, habit, health, vehicle, tool, idea, goal
But you can use any type (lowercase): recipe, dream, memory, quote, book, movie, emotion, relationship, appointment, medication, exercise, symptom, payment, contract, etc.
The LLM will intelligently reuse existing types when appropriate to maintain consistency.
The true value of this memory system lies not just in storing individual memories, but in creating connections between them. A knowledge graph becomes exponentially more useful as you build relationships:
Context Discovery: Connected memories provide rich context that isolated facts cannot
Relationship Patterns: Reveal hidden patterns and insights through relationship analysis
Temporal Understanding: Track how relationships evolve over time
Network Effects: Each new connection increases the value of existing memories
Always look for relationships when storing new information:
Bad: Just store "John is a developer"
Good: Store John AND connect him to his company, projects, skills, and colleaguesUse semantic relationship types that capture meaning:
WORKS_AT, MANAGES, KNOWS, LIVES_IN, CREATED, USES, LEARNED_FROMAdd relationship properties for richer context:
create_connection({
"fromMemoryId": 123,
"toMemoryId": 456,
"type": "WORKS_ON",
"properties": {"role": "Lead", "since": "2023-01", "hours_per_week": 20}
})Think in graphs: When recalling information, use depth > 1 to explore the network:
search_memories({"query": "John", "depth": 3}) // Explores connections up to 3 hops awayRemember: A memory without connections is like a book in a library with no catalog - it exists, but its utility is limited. The more you connect your memories, the more intelligent and useful your knowledge graph becomes.
Run the test suite:
npm testFor interactive testing and debugging, use the MCP Inspector:
# Quick start with environment variables from .env
./run-inspector.sh
# Or manually with specific environment variables
NEO4J_URI=bolt://localhost:7687 \
NEO4J_USERNAME=neo4j \
NEO4J_PASSWORD=your-password \
npx @modelcontextprotocol/inspector build/index.jsThe inspector provides a web UI to:
Test all available tools interactively
See real-time request/response data
Validate your Neo4j connection
Debug tool parameters and responses
MIT
Create a connection between two memories (its good to have connected memories)
| Name | Required | Description | Default |
|---|---|---|---|
| fromMemoryId | Yes | ID of the source memory | |
| toMemoryId | Yes | ID of the target memory | |
| type | Yes | Relationship type such as KNOWS, WORKS_ON, LIVES_IN, HAS_SKILL, PARTICIPATES_IN | |
| properties | No | Optional relationship metadata (e.g. {since: "2023-01", role: "Manager", status: "active"}) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Create' implying a write operation but doesn't disclose behavioral traits like permissions needed, whether connections are reversible, error conditions, or rate limits. The phrase 'its good to have connected memories' adds minimal context without practical details.
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 brief with one sentence, but 'its good to have connected memories' is redundant and doesn't add operational value. It could be more front-loaded with essential usage information, though it avoids excessive verbosity.
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 no annotations and no output schema, the description is incomplete for a mutation tool. It lacks details on what happens upon creation, error handling, or return values, leaving significant gaps for an AI agent to understand the tool's behavior fully.
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 parameters are well-documented in the schema. The description adds no additional meaning beyond the schema, such as explaining relationship types or property usage. 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 verb 'Create' and resource 'connection between two memories', making the purpose understandable. However, it doesn't distinguish this from sibling tools like 'update_connection' or specify what makes a connection 'good' versus just possible.
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 minimal guidance with 'its good to have connected memories', which is vague and doesn't specify when to use this tool versus alternatives like 'update_connection' or prerequisites. No explicit when/when-not or alternative tool references are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new memory in the knowledge graph. Consider that the memory might already exist, so Search → Create → Connect (its important to try and connect memories)
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | Memory label in lowercase (use list_memory_labels first to check existing labels for consistency) - common: person, place, organization, project, event, topic, object, animal, plant, food, activity, media, skill, document, meeting, task, habit, health, vehicle, tool, idea, goal | |
| properties | Yes | Information to store about this memory (use "name" as primary identifier, e.g. {name: "John Smith", age: 30, occupation: "Engineer"}) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the 'Search → Create → Connect' workflow which adds important context about checking for existing memories, but doesn't disclose other behavioral traits like whether this is a write operation (implied by 'Create'), what permissions are needed, error handling, or what happens on duplicate creation attempts beyond the workflow advice.
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 appropriately sized with two sentences that each serve distinct purposes: the first states the core function, the second provides important workflow guidance. It's front-loaded with the primary purpose and avoids unnecessary elaboration, though the workflow advice could be slightly more concise.
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 creation tool with 2 parameters, 100% schema coverage, but no annotations and no output schema, the description provides adequate context about the workflow but lacks details about behavioral aspects like error conditions, response format, or creation constraints. The workflow guidance is helpful but doesn't fully compensate for the missing structured information.
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?
With 100% schema description coverage, the baseline is 3. The description adds value by explaining the overall workflow context ('Search → Create → Connect') and the importance of checking existing labels, which provides semantic context beyond the schema's technical parameter descriptions. However, it doesn't add specific details about parameter usage beyond what's in the schema.
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 a new memory') and resource ('in the knowledge graph'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'update_memory' or 'search_memories' beyond mentioning the Search → Create → Connect workflow, which is more about usage guidance than sibling differentiation.
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 clear context about when to use this tool through the Search → Create → Connect workflow, advising to check for existing memories first. It implies alternatives like 'search_memories' and 'list_memory_labels' but doesn't explicitly name them or specify when NOT to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a specific connection between two memories (use with caution - this permanently removes the relationship)
| Name | Required | Description | Default |
|---|---|---|---|
| fromMemoryId | Yes | ID of the source memory | |
| toMemoryId | Yes | ID of the target memory | |
| type | Yes | Exact relationship type to delete (e.g. WORKS_AT, KNOWS, MANAGES) |
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 effectively communicates the destructive nature ('permanently removes') and irreversible consequence ('use with caution'), which are critical for a deletion operation. It doesn't mention authentication requirements, rate limits, or error conditions, but covers the most important behavioral aspect for this type of 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 perfectly concise - a single sentence that communicates the core purpose upfront, followed by a crucial cautionary note. Every word earns its place, with no redundancy or unnecessary elaboration. The structure is front-loaded with the primary action.
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 operation with no annotations and no output schema, the description provides adequate context about the permanent nature of the action. It could benefit from mentioning what happens after deletion (e.g., whether it returns confirmation) or error scenarios, but given the straightforward nature of the operation and complete parameter documentation, it's reasonably complete.
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 all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (it doesn't explain the meaning of 'connection' or provide additional context about the parameters). This meets the baseline expectation when schema coverage is complete.
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 specific action ('Delete a specific connection') and resource ('between two memories'), distinguishing it from sibling tools like delete_memory (which deletes memories themselves) and update_connection (which modifies rather than removes connections). The verb+resource combination is precise and unambiguous.
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 implied usage guidance through the cautionary note ('use with caution - this permanently removes the relationship'), suggesting this should be used when permanent removal is intended. However, it doesn't explicitly state when to use this versus alternatives like update_connection for modifying relationships or when deletion is preferred over other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a memory and all its connections (use with caution - this permanently removes the memory and all its connections)
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | ID of the memory to delete |
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 effectively communicates the destructive nature ('permanently removes'), scope ('all its connections'), and caution needed. However, it lacks details on permissions, error handling, or confirmation steps, leaving some behavioral aspects unspecified.
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 front-loaded with the core action and includes a necessary warning in a single, efficient sentence. Every word earns its place, with no redundancy or unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with no annotations or output schema), the description is mostly complete by emphasizing permanence and scope. However, it could improve by mentioning potential side effects (e.g., impact on connected data) or success/error responses, leaving minor gaps in full 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?
The input schema has 100% description coverage, with 'nodeId' clearly documented as 'ID of the memory to delete.' The description does not add any additional meaning or context about the parameter beyond what the schema provides, so it meets the baseline for high schema coverage without 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 specific action ('Delete a memory and all its connections') and distinguishes it from sibling tools like 'delete_connection' (which only deletes connections) and 'update_memory' (which modifies rather than removes). The verb 'delete' is precise and the resource 'memory' is explicitly identified.
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 clear context with the warning 'use with caution - this permanently removes the memory and all its connections,' which implies this tool should be used for irreversible deletion. However, it does not explicitly state when to use alternatives like 'update_memory' for modifications or 'delete_connection' for partial removal, missing explicit sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get help on using the memory tools effectively
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Topic: connections, labels, relationships, best-practices, examples, or leave empty for all |
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 provides 'help' but does not specify what form this help takes (e.g., textual advice, examples, documentation), whether it requires authentication, or any rate limits. This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
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: 'Get help on using the memory tools effectively.' It is front-loaded with the core purpose, has no unnecessary words, and efficiently communicates the tool's intent without redundancy, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and high schema coverage, the description is adequate for basic understanding. However, with no annotations and no output schema, it fails to provide details on behavioral aspects (e.g., response format, error handling) or deeper context, which could be important for effective use. It meets minimum viability but has clear gaps in completeness.
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 the 'topic' parameter well-documented in the schema itself. The description does not add any additional meaning or context beyond what the schema provides (e.g., it doesn't explain the significance of topics like 'best-practices'). Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't 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: 'Get help on using the memory tools effectively.' It specifies the verb ('Get help') and the resource ('memory tools'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_memory_labels' or 'search_memories' in terms of its advisory versus operational nature, 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 implies usage context ('using the memory tools effectively'), suggesting it should be used for guidance rather than direct operations. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., when to seek help versus directly using tools like 'create_memory'), and does not mention any exclusions or prerequisites, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all unique memory labels currently in use with their counts (useful for getting an overview of the knowledge graph)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool's behavior of listing labels with counts, which is useful. However, it doesn't mention potential limitations like pagination, sorting, or performance implications for large datasets, leaving gaps 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 a single, well-structured sentence that efficiently conveys purpose and utility without any wasted words. It is front-loaded with the core action and includes a helpful parenthetical note.
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 adequate but minimal. It explains what the tool does but lacks details on output format (e.g., structure of the list) or error conditions, which could be helpful despite the low complexity.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. A baseline of 4 is applied for zero-parameter tools when schema coverage is complete.
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 verb ('List') and resource ('all unique memory labels currently in use') with specific scope ('with their counts'). It distinguishes from siblings like 'search_memories' by focusing on labels overview rather than memory content.
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 clear context ('useful for getting an overview of the knowledge graph'), indicating when to use this tool. However, it doesn't explicitly state when not to use it or name specific alternatives among siblings like 'search_memories' for different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and retrieve memories from the knowledge graph
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search text to find in any property (searches for ANY word - e.g. "Ben Weeks" finds memories containing "Ben" OR "Weeks") | |
| label | No | Filter by memory label | |
| depth | No | Relationship depth to include, defaults to 1 | |
| order_by | No | Sort order such as created_at DESC, name ASC | |
| limit | No | Maximum results to return, defaults to 10, max 200 | |
| since_date | No | ISO date string to filter memories created after this date (e.g., "2024-01-01" or "2024-01-01T00:00:00Z") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'search and retrieve' which implies a read-only operation, but doesn't specify permissions needed, rate limits, pagination behavior, error conditions, or what 'retrieve' entails (e.g., full memory details vs summaries). For a search tool with 6 parameters and no annotations, 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 a single, efficient sentence that front-loads the core purpose ('Search and retrieve memories from the knowledge graph') with zero wasted words. It's appropriately sized for a tool with a clear primary function, making it easy 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 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'retrieve' returns (e.g., memory objects, IDs, or summaries), how results are structured, or any behavioral aspects like error handling. For a search tool with moderate complexity, this leaves too much unspecified for reliable 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 100%, with each parameter well-documented in the schema (e.g., query searches for ANY word, depth defaults to 1, limit max 200). The description adds no additional parameter information beyond the schema, so it doesn't enhance understanding. Baseline 3 is appropriate when the schema does all the work.
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 ('Search and retrieve') and resource ('memories from the knowledge graph'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential sibling search operations (none listed in siblings, but 'list_memory_labels' is a related read operation). The description is specific but lacks sibling differentiation.
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 siblings like 'list_memory_labels' (which might list all labels without search) and other CRUD operations, there's no indication of when search is preferred over listing or when this tool should be avoided. No context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update properties of an existing connection between memories
| Name | Required | Description | Default |
|---|---|---|---|
| fromMemoryId | Yes | ID of the source memory | |
| toMemoryId | Yes | ID of the target memory | |
| type | Yes | Relationship type to identify which connection to update (e.g. WORKS_AT, KNOWS, MANAGES) | |
| properties | Yes | Properties to update/add (e.g. {status: "completed", end_date: "2024-01"}) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) but doesn't address permissions needed, whether changes are reversible, rate limits, or what happens if the connection doesn't exist. The description adds minimal behavioral context beyond what's implied by 'update'.
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 states the core purpose without unnecessary words. It's appropriately sized for a straightforward update operation and front-loads the essential information ('Update properties of an existing connection').
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 and no output schema, the description is inadequate. It doesn't explain what 'properties' can be updated, what the response looks like, error scenarios, or how this differs from sibling tools. Given the complexity (4 required params including nested objects), more context is needed for the agent to use this effectively.
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 all 4 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema descriptions (e.g., examples of 'type' values and 'properties' content are already in schema). Baseline 3 is appropriate when 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 verb ('Update') and resource ('properties of an existing connection between memories'), making the purpose immediately understandable. It distinguishes from siblings like 'create_connection' (creates new) and 'delete_connection' (removes), though it doesn't explicitly mention these alternatives in the description text itself.
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_connection' or 'update_memory'. It doesn't mention prerequisites (e.g., connection must exist), error conditions, or typical use cases, leaving the agent to infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update properties of an existing memory such as adding more detail or make a change when you find out something new
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | ID of the memory to update | |
| properties | Yes | Properties to update/add |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'update properties' but fails to specify whether this is a partial or full update, what happens to unmentioned properties, permission requirements, or error handling. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits unclear.
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 purpose. It avoids redundancy and wastes no words, though it could be slightly more structured for clarity. Every phrase contributes meaning, earning its place.
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 mutation operation with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, error cases, and return values, leaving gaps that could hinder an agent's ability to use the tool effectively in 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 100%, so the schema already documents both parameters ('nodeId' and 'properties'). The description adds marginal value by implying 'properties' can include new details or changes, but it doesn't provide syntax, format, or constraints beyond what the schema offers. Baseline 3 is appropriate when the schema handles most documentation.
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 verb ('update') and resource ('existing memory') with specific examples of actions ('adding more detail or make a change when you find out something new'). It distinguishes from sibling 'create_memory' by specifying 'existing memory,' though it doesn't explicitly differentiate from other update operations like 'update_connection.'
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 minimal guidance, only implying usage when new information is found or details need addition. It lacks explicit when-to-use scenarios, prerequisites, or comparisons to alternatives like 'create_memory' or 'search_memories,' leaving the agent with insufficient context for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
create_connectioncreate_memorydelete_connectiondelete_memoryget_guidancelist_memory_labelssearch_memoriesupdate_connectionupdate_memoryEach tool has a clearly distinct purpose: create/delete/update operations for memories and connections, plus search, list, and guidance tools. There is no overlap in functionality, making it easy for an agent to select the correct tool.
All tool names follow a consistent verb_noun pattern (e.g., create_memory, delete_connection, update_memory). The naming is uniform and predictable, with no deviations in style or convention.
With 9 tools, the server is well-scoped for managing a knowledge graph, covering essential CRUD operations for memories and connections, plus auxiliary functions like search and guidance. Each tool earns its place without bloat.
The toolset provides complete lifecycle coverage for memories and connections (create, read via search, update, delete), along with utilities for listing labels and getting guidance. There are no obvious gaps for the domain of memory management in a knowledge graph.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Shared long-term memory for AI agents: save and recall context as a searchable knowledge graph.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/knowall-ai/mcp-neo4j-agent-memory'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
