knowall-ai/mcp-reverie

**Reverie** is KnowAll AI's Neo4j knowledge-graph memory for AI agents, served over MCP. It is published on npm as @knowall-ai/reverie (successor to the legacy package @knowall-ai/mcp-neo4j-agent-memory). 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.
Why 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.
Quick Start 🚀
You can run this MCP server directly using npx:
Or add it to your Claude Desktop configuration:
Features
- 🧠 **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
Philosophy: LLM-Driven Intelligence
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 Behavior
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
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.