How to Give Claude & Cursor Persistent Memory 2026

Install the free official MCP memory server, then upgrade to project-aware ContextForge. 2026 guide.

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.