MCP Memory Server: How to Give Claude & Cursor Persistent Memory (2026)

Here's a small tragedy that plays out in my terminal every single morning: I open Claude Code, and it has no idea who I am, what I'm building, or what we decided yesterday. Same with Cursor. Brilliant assistants, zero memory. It's like working with a genius who has amnesia.

The fix is an MCP memory server — a little service that plugs into Claude or Cursor over the Model Context Protocol and gives your assistant memory that survives when the session ends. In this guide I'll show you exactly how to set one up, starting with the free official server and then the project-aware option I ended up building because the official one wasn't enough for real work.

New to this whole space? I ranked the 8 best AI memory tools for Claude and did a deep ContextForge vs Mem0 vs Zep comparison in separate posts. This one is the hands-on how to actually install one guide.

What is an MCP memory server?

MCP — the Model Context Protocol — is the open standard that lets tools like Claude Code and Cursor talk to external services. An MCP memory server is just one of those services, with one job: store what your assistant learns (facts, decisions, project context) and hand the right pieces back at the start of the next conversation.

Without one, everything your assistant knows lives inside a single session's context window — and vanishes the moment that session closes. With one, memory lives outside the model, so tomorrow's you doesn't start from zero.

Two ways to get there, from simplest to most capable. Let's do both.

Option 1: The official MCP memory server (free, 2 minutes)

The Model Context Protocol team ships a reference memory server. It's a knowledge-graph memory that stores entities, relations, and observations in a local JSON file. It's the fastest way to feel what MCP memory does, and it costs nothing.

Install it in Claude Code / Claude Desktop. Open your MCP config (claude_desktop_config.json, or .mcp.json in your project) and add:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

Install it in Cursor. Same idea — add the block to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

Restart the app, and your assistant can now save and recall entities across sessions. That's genuinely useful — and for a lot of people it's enough.

Where it stops being enough. I ran the official server for weeks, and three things wore me down:

• It's one flat graph in a local file — no notion of which project a memory belongs to. My side project's facts and my client work bled into the same blob.

• No sync. The memory lives on one machine; switch laptops or tools and it doesn't follow you.

• You have to babysit recall. Nothing loads automatically at session start — you're nudging it to remember, every time.

For quick experiments, perfect. For the actual work I do every day, I wanted something that understood projects. So I built it.

Option 2: ContextForge — a project-aware MCP memory server

ContextForge is an MCP memory server too — same standard, plugs into Claude and Cursor the same way — but instead of one flat graph, it organizes memory around your projects: spaces, items, tasks, and decisions that load automatically the second a new session starts. No vector database to run, no local file to babysit.

Connect it the same way you connected the official one — add it to your MCP config, drop in your ContextForge API key, and restart. From that point on, when you open Claude Code or Cursor, your assistant already knows what project you're in and what you were doing. You can even import the ChatGPT and Claude history you already have, so you're not starting your memory from scratch.

Here's the honest side-by-side:

Neither is "the winner" in the abstract. If you want a free, local, kick-the-tires memory, the official server is a great first stop. If you live in Claude Code or Cursor and want memory that actually understands your projects and follows you around, that's the gap ContextForge was built to fill.

Which should you pick?

• Just curious how MCP memory feels? → the official @modelcontextprotocol/server-memory. Free, two minutes, done.

• Working on real projects across sessions, machines, or tools? → ContextForge.

• Not sure which memory tool at all yet? → start with my top-8 ranking.

FAQ

What is an MCP memory server? It's a service that connects to Claude, Cursor, or any MCP client over the Model Context Protocol and stores your assistant's memory outside the session, so facts, decisions, and project context persist across conversations instead of resetting each time.

How do I install the official MCP memory server? Add @modelcontextprotocol/server-memory to your MCP config (claude_desktop_config.json, .mcp.json, or ~/.cursor/mcp.json) with the command npx -y @modelcontextprotocol/server-memory, then restart the app.

Does this work with both Claude Code and Cursor? Yes. Both speak MCP, so the same memory server plugs into either one — you just add the server to each tool's MCP config file.

What's the difference between the official server and ContextForge? The official server stores one flat knowledge graph in a local file. ContextForge organizes memory by project (spaces, tasks, decisions), loads it automatically at session start, needs no local infrastructure, and syncs across your tools and machines.

Do I need a vector database? No. Neither the official server nor ContextForge asks you to run a vector database — that's part of the appeal of an MCP memory server over building recall yourself.

Tired of re-introducing your project to Claude and Cursor every morning? I built ContextForge to be the MCP memory server I wanted — project-aware, zero infrastructure, connected in minutes.