The short version: OpenMemory MCP is a private memory server you run on your own machine. It speaks the Model Context Protocol, so tools like Cursor, Claude Desktop, Cline, and Windsurf all connect to the same persistent memory instead of each keeping its own siloed context. You clone the Mem0 repo, drop in an OPENAI_API_KEY, run make build && make up, and you get a dashboard at http://localhost:3000 and an MCP server at http://localhost:8765. Memory is stored locally in Qdrant (vectors) and Postgres — nothing about your memories is sent to a cloud service. It exposes four tools over MCP: add_memories, search_memory, list_memories, and delete_all_memories.

That is the whole pitch. The rest of this piece is who should bother, the exact commands, and the honest tradeoffs.

Who this is actually for#

You want OpenMemory MCP if you are a solo developer or founder who (a) bounces between multiple AI coding tools, and (b) does not want your accumulated context — preferences, project facts, decisions, past bugs — living on someone else's servers.

The single non-obvious insight: the value is not storage, it is the handoff. Every MCP client already remembers something within its own walls. What none of them do alone is share. Tell Cursor "this project uses pnpm, not npm, and we never use default exports," then open Claude Desktop later and it already knows — because both wrote to and read from the same local store. That cross-tool continuity is the feature. If you only ever use one tool, a local memory server is a smaller win.

If you are still deciding on a memory layer at all, the broader landscape is worth a look first: see Mem0 vs Zep vs Letta and Cognee vs Graphiti vs Mem0.

What it is under the hood#

OpenMemory MCP is the local, self-hosted face of Mem0. When it runs, Docker brings up a small stack:

The important boundary: your memory content stays on the box. The one thing that leaves is text sent to your configured LLM/embedding provider — OpenAI by default — to create embeddings and extract facts. If that matters to you, OpenMemory supports swapping in local providers like Ollama, which closes even that gap.

Setup, step by step#

You need Docker and Docker Compose installed and running. Then clone the repo and move into the openmemory directory:

git clone https://github.com/mem0ai/mem0.git
cd mem0/openmemory

Create the backend environment file and add your key:

cp api/.env.example api/.env
# then edit api/.env and set:
#   OPENAI_API_KEY=sk-...
#   USER=your-user-id        # the owner id memories are filed under

Build the images and start everything:

make build
make up

There is also a one-liner if you prefer not to clone manually — it fetches and runs the project's setup script:

curl -sL https://raw.githubusercontent.com/mem0ai/mem0/main/openmemory/run.sh | bash

(Piping a remote script to bash is convenient but you are trusting the URL — read it first if you care, which you should.)

Once the stack is up:

Open the dashboard to confirm it is alive before wiring any clients in.

The MCP tools it exposes#

Any connected client sees four tools. This is the entire memory API surface:

ToolWhat it does
add_memoriesStore new memory objects (facts, preferences, context).
search_memoryRetrieve memories by semantic meaning, not keyword match.
list_memoriesReturn everything currently stored for the user.
delete_all_memoriesWipe the store.

These are MCP tools — model-invoked actions — not resources or prompts. If that distinction is fuzzy, tools vs resources vs prompts untangles it. In practice the model decides when to call add_memories and search_memory on its own, guided by your system prompt telling it to remember and recall.

Wiring it into a client#

The MCP server exposes a per-client SSE endpoint following this pattern:

http://localhost:8765/mcp/<client-name>/sse/<user-id>

The <user-id> is the USER value from your .env. You do not have to write the client config by hand — Mem0 ships an installer that patches the target tool's MCP configuration for you:

npx @openmemory/install local \
  http://localhost:8765/mcp/<client-name>/sse/<user-id> \
  --client <client-name>

For Cursor, that becomes concrete:

npx @openmemory/install local \
  http://localhost:8765/mcp/cursor/sse/rosa \
  --client cursor

Swap --client cursor for claude, cline, or windsurf and adjust the <client-name> segment in the URL to match. Restart the tool, and the four memory tools appear in its MCP tool list. If a client prefers raw JSON, the equivalent config is a standard SSE MCP entry:

{
  "mcpServers": {
    "openmemory": {
      "url": "http://localhost:8765/mcp/cursor/sse/rosa"
    }
  }
}

A known gotcha: if a client 404s on a messages route, double-check you used the full /mcp/<client>/sse/<user-id> path and not a truncated URL — that mismatch is the usual culprit.

Local vs cloud: the real tradeoff#

The privacy win is genuine and it is the reason to do this. But be clear-eyed about the cost:

One forward-looking note worth your attention: Mem0 has been steering serious self-hosters toward its newer Mem0 self-hosted server for local deployments with a dashboard. OpenMemory MCP still runs and does exactly what this guide describes, but if you are choosing a foundation for the long haul, check the repo's current README for which self-hosted path the team is actively investing in before you build heavily on top of it.

For a single privacy-conscious founder who lives in two or three MCP tools on one workstation, though, OpenMemory MCP is the fastest route to memory that follows you across all of them — and never leaves your desk.