Start a Claude Code session. Explain your project architecture. Debug a tricky issue. Close the session.

Open a new session tomorrow. The model knows nothing. You explain the architecture again. You re-describe the bug you fixed yesterday because today's related issue needs the same context.

This is the memory problem in AI-assisted development. Models don't remember. Every session starts blank. Every context window resets to zero.

MCP memory tools are an emerging answer: local storage backends, accessible through the Model Context Protocol, that give AI coding clients persistent memory across sessions and tools.

What MCP memory is

The Model Context Protocol (MCP) is a standard for connecting AI models to external tools and data sources. An MCP server exposes capabilities — reading files, querying databases, calling APIs — that any MCP-compatible client can use.

MCP memory tools are MCP servers specifically designed to store and retrieve contextual knowledge. They run locally, store data in files or lightweight databases (SQLite, JSON, markdown), and expose read/write operations that AI clients call during sessions.

The architecture:

┌──────────────┐     MCP protocol     ┌───────────────────┐
│  AI client   │◄────────────────────►│  MCP memory server │
│  (Claude,    │                      │  (local process)   │
│   Cursor,    │  store/retrieve      │                    │
│   Codex)     │  memory operations   │  SQLite / JSON /   │
│              │                      │  markdown files    │
└──────────────┘                      └───────────────────┘

The AI client calls the memory server to store facts it learns during a session and retrieve them in future sessions. The storage is local — on your machine, in your project directory, under your control.

Why local storage matters

Cloud-based memory (like Anthropic's built-in memory for Claude) is convenient but limited:

You can't inspect what it stored
You can't edit or delete specific memories
You can't share memories across tools
You can't version-control memories with your project
You can't guarantee where the data lives

Local MCP memory flips all of these:

Inspectable. Memories are files on disk. Open them, read them, grep them.
Editable. Wrong memory? Edit the file. Stale context? Delete it.
Portable. Any MCP-compatible client reads the same storage. Switch from Cursor to Claude Code and your memories come along.
Version-controlled. Commit your memory files to git. Track what the model knows about your project over time.
Private. Nothing leaves your machine unless you push it.

What gets stored

MCP memory tools typically store three categories of information:

Project facts

Architectural decisions, file relationships, conventions. "The auth middleware is in src/middleware/auth.ts." "We use Zod for validation, never joi." "The deploy script requires Node 20+."

These are the things you'd put in a CLAUDE.md, but discovered and maintained by the model during actual work instead of written upfront by a human.

Session summaries

What happened in previous sessions. "Yesterday we debugged a race condition in the queue worker — the fix was adding a mutex around the publish step." "Last week we refactored the billing module to use Stripe's new API."

Session summaries let the model pick up where it left off without you re-explaining the history.

Learned preferences

How you like to work. "This developer prefers early returns over nested ifs." "Always suggest the simplest solution first." "Don't refactor surrounding code when fixing a bug."

These are behavioral memories that make the model feel like it knows you, not just your code.

The cross-client promise

The most compelling aspect of MCP memory is tool portability. If your memory server stores facts in a standard format and speaks MCP, any compatible client can access it.

In practice, this means:

You teach Claude Code about your project conventions during a long session
Those conventions are stored locally via the MCP memory server
You open Cursor tomorrow. It connects to the same MCP memory server
The conventions are there. No re-teaching.

This breaks the lock-in cycle where switching tools means losing all the context you've built up. Your memory belongs to you, not to the tool.

How to set it up

Most MCP memory tools follow the same pattern:

Install the memory server (usually an npm package or Python package)
Configure your AI client to connect to it
The model starts using it automatically during sessions

A typical MCP client configuration:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["@your-memory-server/mcp"],
      "env": {
        "MEMORY_DIR": "./memories"
      }
    }
  }
}

The memory directory lives in your project. The server reads and writes files there. The AI client calls the server through MCP to store and retrieve memories.

Storage patterns

Different memory tools use different storage backends, each with tradeoffs:

Markdown files — one file per memory or per category. Human-readable, git-friendly, easy to edit. Slower for large memory sets because every retrieval scans files.

SQLite — single database file. Fast queries, supports semantic search with extensions. Less human-readable, but still portable and version-controllable.

JSON files — structured, machine-readable, easy to process. Harder to read at a glance than markdown. Good for memory tools that need metadata (timestamps, tags, confidence scores).

Hierarchical files — memories organized in a directory tree by project, topic, and specificity. Good for large codebases where you need scoped retrieval ("only memories about the auth module").

The trend is toward markdown or hierarchical files, because developers want to read and edit their AI's memories the same way they read and edit their code.

What to watch for

Memory bloat. Without cleanup, memory stores grow indefinitely. Stale facts about code that's been refactored, session summaries from months ago, preferences that no longer apply. Good memory tools include expiry or relevance scoring.

Conflicting memories. "We use PostgreSQL" stored six months ago, but you migrated to SQLite last month. If the old memory isn't removed, the model gets contradictory context. Human review of memories is still important.

Retrieval relevance. Storing everything is easy. Retrieving the right memories for the current task is hard. Keyword matching misses semantic connections. Embedding-based search adds complexity and compute. The retrieval problem is the main differentiator between memory tools.

Privacy in shared repos. If you commit memory files to git, everyone on the team sees them. Personal preferences ("this developer prefers verbose explanations") might not belong in a shared repo. Separate personal from project memories.

Where this is going

MCP memory is early. The protocol is standardized, but memory schemas aren't. Each tool stores memories differently, uses different retrieval strategies, and has different opinions about what to remember.

The convergence will happen around a few patterns:

Standard memory schemas that multiple tools can read and write
Semantic retrieval that fetches relevant memories without exact keyword matches
Memory lifecycle management — auto-expiry, conflict detection, importance scoring
Team-shared vs personal memory — project facts shared, work preferences private

The end state is AI coding context that's as portable as your dotfiles: checked into your repo, synced across machines, readable by any tool. We're not there yet, but MCP memory tools are the clearest path.