It is an MCP server that gives AI agents a persistent Neo4j knowledge-graph memory with search, entity/relationship management, and graph maintenance.
Memory storage & retrieval: create memories with labels/properties, search using hybrid/keyword/semantic/exact modes, filter by label/date, sort, limit, and explore relationships by depth.
Graph relationships: create typed connections (KNOWS, WORKS_AT, etc.) with metadata, update or delete connections, and delete memories along with all their connections.
Consistency & exploration: list memory labels with counts, run read-only Cypher queries, and get graph statistics.
Maintenance: dream merges duplicates, canonicalizes labels, refreshes embeddings, reports bloated nodes, and supports dry-run.
Guidance: get_guidance provides best practices on labels, relationships, and usage examples.
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.
Reverie is KnowAll AI's Neo4j knowledge-graph memory for AI agents, served over MCP. Until @knowall-ai/reverie is published to npm, install the legacy package @knowall-ai/mcp-neo4j-agent-memory (0.2.x). The GitHub repository is now knowall-ai/mcp-reverie, and old URLs redirect.
Reverie turns an agent's memory from a pile of facts into a map of the entities in its world and how they relate, and keeps that map healthy. It is an MCP server, so any agent that speaks the Model Context Protocol (Claude Desktop, OpenClaw, Azure AI Foundry, Cursor…) gets the same graph; a Hermes Agent memory-provider flavour lives in hermes-reverie.
A typed entity graph, not a fact store. People, organisations, projects, places, concepts, meetings and decisions are nodes with typed relationships. "Who at the Irish FA have we talked to about Winnie?" is a graph walk, not a similarity search.
Search that finds "Ben" when you say "Benjamin". Hybrid keyword + semantic search, with local embeddings by default (no API key) and OpenAI, Azure OpenAI, Ollama or Voyage a config switch away.
It dreams. A dream tool merges duplicates safely, canonicalises labels, re-embeds, counts orphans and flags nodes that have become property dumps, so a nightly job can keep the graph clean.
One graph, any agent. KnowAll runs Sallie (OpenClaw) and Poppie (Hermes) against the same conventions; Reverie is how they share what they know.
LLM-driven, transparent tools. Simple atomic operations; the model does the entity recognition and conflict resolution, and every action is explicit.
Yours to run. Neo4j on your own machine or VM. Nothing leaves it unless you choose a remote embedding provider.
Related MCP server: Neo4j Memory Server
You can run this MCP server directly using npx:
npx @knowall-ai/mcp-neo4j-agent-memory # becomes `npx @knowall-ai/reverie` once 0.4.0 is publishedOr 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"
}
}
}
}🧠 Persistent Memory Storage - Store and retrieve memories across conversations
🔗 Semantic Relationships - Create meaningful connections between memories (KNOWS, WORKS_AT, CREATED, etc.)
🔍 Hybrid Search - Keyword plus semantic search across all memory properties, with local embeddings by default
🏷️ 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
search_memories is hybrid: keyword hits (any word of the query as a substring of any searchable content property) rank first, then semantic matches above a similarity threshold. See Search below.
This approach makes the system more powerful and adaptable, as improvements in LLM capabilities directly translate to better memory management.
search_memories now supports three modes:
hybrid (default): keyword hits score 1, then semantic matches add close variants such as Benjamin Weeks for Ben Weeks
keyword: any word of the query as a substring of any searchable content property (timestamps, status and embedding fields are never matched)
semantic: uses embeddings only when available, with graceful fallback to keyword behavior if embeddings are unavailable
exact: case-insensitive equality on name, aliases or email; the precise lookup to run before creating a memory, so "ben weeks" finds exactly "Ben Weeks" and nothing else
Archived memories (status = 'archived') are left out of results and of list_memory_labels unless include_archived: true is passed. Returned relationships carry _start and _end node ids, so a connection's direction is always recoverable.
Use similarity_threshold (default 0.4; must be between 0 and 1, other values are rejected) to control how strict semantic matches are. Results include _score and _match on each returned memory object so callers can explain why a memory was returned.
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
Hybrid search: Blend keyword and semantic search; Ben Weeks can also find Benjamin Weeks
Choose search_mode = hybrid, keyword, or semantic
Tune semantic strictness with similarity_threshold (default 0.4)
Returned memories include _score and _match metadata
Filter by memory type (case-insensitive, so person and Person both work), date, depth, result limit, and sort order
create_memory: Create a new memory in the knowledge graph
Flexible type system - any label that is a plain identifier; Capitalised singular is canonical (Person, Place, Project, Skill…), and dream canonicalises lowercase labels
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
Returns a _hint when the node exceeds the property limit: the graph is for entities and relationships, not a notebook
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
query_memories: Run a read-only Cypher query
Accepts a Cypher string plus optional params
Runs in a Neo4j READ transaction (the server rejects writes), stops after 200 rows, and times out after 10 seconds
Rejects write clauses, CALL subqueries, and any procedure outside a small read-only allow-list (db.labels, db.propertyKeys, db.index.*.query*, schema procedures). For belt and braces, run the server with a read-only Neo4j role where you can
memory_stats: Summarize the current graph
Returns node, relationship, label, relationship-type, embedding, and orphan counts
dream: Deterministically clean up and consolidate the graph
Relabels lowercase labels to their Capitalised form (person → Person), merges same-named nodes within a label when APOC is available, and refreshes embeddings
Merging keeps the survivor's name, timestamps and vectors and combines every other property (conflicting values become lists, nothing is dropped) and skips pairs whose identity fields differ (email, phone, website, company, organisation, organization), so two different "John Smith"s stay separate. The report lists every group under duplicates with what was merged and what was skipped and why. Run with dry_run: true first to review
Reports bloated nodes (more than REVERIE_MAX_PROPERTIES, default 30, real properties) with the keys that look like dated facts or prose, so a nightly sleep can fold them into attributes, relationships or notes
Supports dry_run for a no-write report
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 5.9 or newer (the dream tool uses COUNT {} and IS :: STRING); APOC for duplicate merging
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
Reverie is listed in the MCP Registry as io.github.knowall-ai/reverie (the successor of the "Neo4j Agent Memory" entry that used to sit in the modelcontextprotocol/servers README). server.json in this repository is the listing; the release workflow republishes it on every tag.
To install Reverie 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-reverie.git
cd mcp-reverieInstall 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
Set REVERIE_EMBEDDINGS to choose the embedding provider used by hybrid and semantic search. Changing REVERIE_EMBEDDINGS or REVERIE_EMBEDDING_MODEL causes nodes to be re-embedded lazily on the next search, or eagerly when you run dream.
| Default model | Required env vars |
|
| none; optional |
|
|
|
| deployment-backed |
|
|
| optional |
|
|
|
| disabled | none |
Use REVERIE_EMBEDDING_MODEL to override the model name for any provider. Remote providers batch up to 64 texts per request, time out after REVERIE_EMBED_TIMEOUT_MS (default 30000, max 120000), and must be reached over https; plain http is only accepted for localhost.
The local provider downloads its model (about 23 MB) from Hugging Face on first use and caches it. If that download fails, or any provider errors, search degrades to keyword matching for that call and the error is logged to stderr. Set REVERIE_EMBEDDINGS=none to turn embeddings off entirely.
Each node stores two vectors: embedding (label, name and every text property) and name_embedding (label, name and aliases only), plus embedding_model and embedded_at. A semantic score is the better of the two, so a short query like Ben Weeks still matches a richly described Benjamin Weeks. None of these fields are ever returned by the tools.
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 (Capitalised singular is canonical; lowercase is accepted and canonicalised by dream): 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 (any plain identifier): 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.
npm run build # TypeScript → build/
npm run test:unit # pure-module unit tests + server startup checks, no database needed
npm run test:integration # drives the built server over stdio against a live Neo4j
npm run test:coverage # everything under c8 with a coverage gate (70% lines and functions)The integration tests need a Neo4j 5 with APOC and wipe the database they point at, so give them a disposable one:
docker run -d --rm --name reverie-test-neo4j -p 17687:7687 \
-e NEO4J_AUTH=neo4j/test-password -e NEO4J_PLUGINS='["apoc"]' neo4j:5-community
NEO4J_URI=bolt://127.0.0.1:17687 NEO4J_USERNAME=neo4j NEO4J_PASSWORD=test-password \
REVERIE_TEST_DESTRUCTIVE=1 npm run test:coverageREVERIE_TEST_DESTRUCTIVE=1 is the explicit opt-in: without it the suite refuses to run. With it,
the suite wipes whatever NEO4J_URI points at, so only set it alongside a disposable database.
The suite waits up to a minute for authenticated Bolt before starting, and a remote NEO4J_URI
must use bolt+s:// or neo4j+s:// with a validated certificate (+ssc is refused).
CI runs the same suite against a Neo4j service container on every pull request and fails the build if coverage drops below the gate. The first semantic search downloads the local embedding model (about 23 MB); CI caches it.
For 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
reverie serve)reverie on its own is the stdio MCP server. reverie serve runs the same server over
Streamable HTTP
and adds a read-only Brain API that the KnowAll Agents Portal
Brain tab uses to draw the graph live. One bearer token protects both; only the health check is open.
REVERIE_SERVE_TOKEN=$(openssl rand -hex 24) NEO4J_PASSWORD=… reverie serve
# Reverie HTTP server listening on http://127.0.0.1:8643Variable | Default | Purpose |
| (required) | Bearer token clients must send as |
|
| Bind address; keep it on loopback behind a reverse proxy |
| none | Comma-separated browser origins allowed to call the API (they get CORS headers and preflight answers); requests carrying any other |
|
| Activation log (see below); empty string disables it |
| unset | Optional dream diary folder ( |
|
| Presence HUD files passed through in |
|
| How often the event stream re-reads the graph, host state and activation log |
NEO4J_* and REVERIE_EMBEDDINGS work exactly as in stdio mode.
Endpoint | Auth | Returns |
| none |
|
| bearer | MCP Streamable HTTP (stateless; JSON responses). Any MCP client that speaks Streamable HTTP can use it |
| bearer | The most connected / most recent nodes ( |
| bearer |
|
| bearer | Server-Sent Events: the last 30 |
Node ids in the Brain API are the same numeric ids the tools return, as strings, so activation events and snapshot nodes line up. Archived memories are never shown. Embedding vectors never leave the server.
Activation log. Every search_memories (recall), create_memory / update_memory
(remember), create_connection / update_connection (connect), delete_* (forget) and real
dream run (dream.start / dream.end) appends one JSON line to REVERIE_EVENTS_PATH, whichever
transport served it. It holds ids, names and search terms only, is private to the user (mode 0600), is capped at
5 MB / 5,000 lines, and is what makes the Brain view light up. The graph itself never records what was looked at.
Behind Caddy on an agent's VM:
agent.example.com {
# … the agent's other routes …
handle /reverie/* {
uri strip_prefix /reverie
reverse_proxy 127.0.0.1:8643
}
}and as a service:
[Unit]
Description=Reverie graph memory (HTTP mode)
After=network-online.target
[Service]
User=agent
EnvironmentFile=/home/agent/.config/reverie.env # NEO4J_*, REVERIE_SERVE_TOKEN, REVERIE_EMBEDDINGS…
ExecStart=/usr/bin/reverie serve
Restart=always
RestartSec=3
[Install]
WantedBy=multi-user.targetGive the portal https://<agent host>/reverie as the agent's brainUrl and the same token as
REVERIE_TOKEN.
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-reverie'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
