Click on "Deploy 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., "@mem0-mcp search memories about machine learning projects"
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.
MCP server for self-hosted Mem0 with Qdrant vector search + Neo4j graph memory.
Looking for Mem0 Cloud? The official mem0-mcp-server works with the managed platform at app.mem0.ai. This project is for self-hosted deployments where you run your own Qdrant, Ollama, and Neo4j.
The official MCP server requires a Mem0 Cloud API key. If you self-host Mem0 with your own Qdrant and Ollama, there's no off-the-shelf MCP server that connects to your infrastructure. This one does.
What it connects to:
Qdrant for vector memory (semantic search)
Neo4j for graph memory (entity relationships)
Ollama for embeddings (no OpenAI/Anthropic keys needed)
OpenMemory API for writes (keeps SQLite + Qdrant in sync)
Related MCP server: mem0-mcp-selfhosted
Tool | Description | Backend |
| Semantic search across all memories | Ollama embed + Qdrant |
| Store a new memory | OpenMemory API |
| List all stored memories | Qdrant scroll |
| Delete a memory by ID | API + Qdrant fallback |
| Find entity relationships | Neo4j |
| Get all connections for an entity | Neo4j |
A self-hosted Mem0 stack running somewhere accessible:
Qdrant (vector store)
Ollama with an embedding model (e.g., nomic-embed-text)
OpenMemory API (mem0ai/mem0)
Neo4j 5+ Community or Enterprise (optional, for graph memory)
If these are on a remote server, use SSH tunnels to forward the ports locally.
pip install git+https://github.com/tensakulabs/mem0-mcp.gitclaude mcp add -s user mem0-mcp -- \
uvx --from git+https://github.com/tensakulabs/mem0-mcp.git mem0-mcpOr add to your MCP config manually:
{
"mcpServers": {
"mem0": {
"command": "uvx",
"args": ["--from", "git+https://github.com/tensakulabs/mem0-mcp.git", "mem0-mcp"],
"env": {
"MEM0_QDRANT_URL": "http://127.0.0.1:6333",
"MEM0_OLLAMA_URL": "http://127.0.0.1:11435",
"MEM0_API_BASE": "http://127.0.0.1:8765",
"MEM0_NEO4J_URL": "bolt://127.0.0.1:7687",
"MEM0_NEO4J_PASSWORD": "your-password",
"MEM0_USER_ID": "your-user-id"
}
}
}
}If your Mem0 stack is on a remote server:
ssh -f -N \
-L 8765:127.0.0.1:8765 \
-L 6333:127.0.0.1:6333 \
-L 11435:127.0.0.1:11434 \
-L 7687:127.0.0.1:7687 \
user@your-serverAll via environment variables with sensible defaults:
Variable | Default | Description |
|
| OpenMemory API (for writes) |
|
| Qdrant REST API |
|
| Ollama (for embeddings) |
|
| Embedding model name |
|
| Qdrant collection name |
|
| User ID for memory filtering |
|
| Neo4j Bolt endpoint |
|
| Neo4j username |
|
| Neo4j password |
Claude Code / Claude Desktop
└── MCP stdio → mem0-mcp
├── READS → Qdrant (vector search, all memories)
├── SEARCH → Ollama (embed query) + Qdrant (similarity)
├── GRAPH → Neo4j (entity relationships)
└── WRITES → OpenMemory API (SQLite + Qdrant sync)Why hybrid read/write? The OpenMemory API uses SQLite as its source of truth for the memory list. If other agents (like OpenClaw) write directly to Qdrant, the API won't see those memories. Reading from Qdrant directly sees everything. Writing through the API keeps both stores in sync.
MIT
Store a new memory for future recall.
Use this to remember important facts, user preferences, architectural
decisions, project context, and lessons learned.
Args:
text: The fact or information to remember (e.g., "Justin prefers
TypeScript over Python for new projects")
Inputs: text (required). Returns: result
Delete a specific memory by its ID.
Args:
memory_id: The full UUID of the memory to delete
Inputs: memory_id (required). Returns: result
Get all relationships for a specific entity.
Returns both incoming and outgoing connections.
Args:
name: The entity name (e.g., "Justin", "TypeScript", "Hetzner")
Inputs: name (required). Returns: result
List all stored memories for the current user.
Returns all memories from both Arc and Atlas in the shared store.
Inputs: no named parameters. Returns: result
Search the knowledge graph for entity relationships.
Finds entities matching the query and their connections.
Use this to understand relationships between people, projects,
technologies, and concepts.
Args:
query: Entity or topic to search for (e.g., "Justin", "OpenClaw",
"Hetzner server")
Inputs: query (required). Returns: result
Semantically search memories for relevant context.
Use this at the start of tasks to recall relevant preferences,
decisions, patterns, and facts from previous sessions.
Args:
query: Natural language search query (e.g., "TypeScript preferences",
"server architecture", "coding style")
Inputs: query (required). Returns: result
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 6 tools
Tools are mostly distinct: add, delete, list, search (semantic and graph) each target different operations. However, search_memories and search_graph could be confused if descriptions aren't carefully read, as both involve searching.
All tool names follow a consistent verb_noun pattern (e.g., add_memory, delete_memory, list_memories, search_memories, get_entity, search_graph). No mixed conventions.
With 6 tools, the set is well-scoped for a memory management server. It covers essential operations without being too few or too many.
The tool surface includes create, read, delete, and search operations. A notable gap is the lack of an update_memory tool, but the set is otherwise functional for the domain.
Self-hosted AI workspace: semantic RAG document search, long-term memory, and AI chat via MCP.
Persistent memory, knowledge graph, task management and more for AI agents via MCP.
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
An MCP memory server. One memory your agents share — across models, devices and apps.
