MCP Memory Servers: Giving Your AI Agents Long-Term Memory

Every LLM conversation starts from zero. Close the chat, start a new one, and the model has no idea it spent an hour yesterday debugging your deployment pipeline with you. This isn't a training limitation — it's architectural. An MCP memory server is the fix that's converged on across the ecosystem: instead of trying to cram more history into the context window, you give the agent a tool it can call to write facts down and a tool it can call to read them back, and you let a small server outside the model own the actual storage. This piece walks through why that pattern works, how the official reference implementation does it, and which third-party memory servers are worth knowing about if the reference server's model doesn't fit your use case.

Why LLMs forget

A large language model has no state between calls. Everything it "knows" about the current conversation is the text sitting in its context window at that moment — the system prompt, the message history, and whatever tool results have been injected. When you start a new chat, that window is empty. When a long conversation gets summarized or truncated to fit a token budget, older details are the first casualty. And when you switch from Claude Desktop to Claude Code to a CI job running the same agent, none of those surfaces share a window at all.

Context windows have grown from a few thousand tokens to several hundred thousand, but that hasn't solved the problem, it's just moved it. A bigger window means you can stuff in more transcript before you have to summarize, but every token in the window still costs money and attention: models demonstrably attend less reliably to information buried in the middle of a long context, a pattern researchers have called "lost in the middle." Pasting your entire project history into every prompt isn't memory, it's just a more expensive way of forgetting slowly.

What you actually want is selective recall: the ability for an agent to store a fact once — "the user prefers TypeScript over JavaScript for new projects," "the staging database is on port 5433," "we decided against using Redis for this cache layer" — and retrieve just that fact, on demand, in a future session that has no other connection to the one where it was learned. That's a storage and retrieval problem, not a context-window problem, and it's exactly the kind of external capability MCP was designed to expose. If you're new to the protocol itself, Getting Started with MCP covers the client-server basics this article builds on.

Memory as an MCP server, not a model feature

The elegant part of solving memory this way is that it keeps the concern separated correctly. The model doesn't need to know how memory is stored — whether it's a graph database, a vector index, or a folder of Markdown files. It just needs a small, stable set of tools: something like save this fact, search for facts about X, and here's everything you know about entity Y. The MCP server behind those tools owns the actual persistence, the indexing strategy, and the retrieval logic, and it can evolve independently of the client or the model.

This also means memory becomes composable the same way any other MCP capability does. You can point Claude Desktop, Claude Code, Cursor, and a custom agent at the same memory server and they all read and write the same store, because the protocol — not the client — defines the interface. Swap the memory server out and, as long as it exposes a similar tool surface, your agents keep working. That's a meaningfully different design from a chatbot's built-in "memory" feature, which is typically a black box tied to one vendor's account and one product surface.

It's worth being precise about what memory servers are not solving. They're not a replacement for retrieval-augmented generation over your document corpus — that's a different job with a different tool shape, and MCP vs RAG covers where that line falls in more detail. A memory server stores facts the agent itself decided were worth remembering, usually accumulated through conversation; a RAG pipeline retrieves passages from a corpus that existed before the conversation started. In practice you often want both.

How memory servers work: the general pattern

Despite different storage backends, most MCP memory servers converge on a similar tool contract:

• A write path for the agent to record something it learned — a fact, an entity, a relationship, or a raw note.
• A search or retrieval path for the agent to pull back relevant memories given a query, usually because it's about to answer something and wants prior context first.
• A read-everything path, useful for smaller memory stores where dumping the whole thing back into context is cheap enough to be worth it.
• Delete or update operations, because memory that can't be corrected becomes a liability rather than an asset.

Where implementations diverge is the storage model underneath those tools, and that choice has real consequences for what the memory is good at. A knowledge graph is good at representing relationships ("Alice works at Acme, which is a client of Bob's team") and lets you traverse them. A vector store is good at fuzzy semantic recall ("something about a caching bug we hit last month") even when you don't remember the exact wording. Plain files are good at being inspectable, versionable, and editable by a human, not just the model.

The official Memory reference server

The Model Context Protocol servers repository — maintained under the modelcontextprotocol GitHub organization — ships a reference implementation simply called Memory, distributed as the npm package @modelcontextprotocol/server-memory. It's a deliberately simple, local, knowledge-graph-based store, meant as both a usable server and a template for building your own.

Its data model has three parts:

• Entities — the nodes of the graph. Each has a unique name, a type (person, project, organization, whatever taxonomy you use), and a list of observations attached to it.
• Relations — directed, active-voice edges between entities, like works_at or depends_on.
• Observations — atomic facts attached to an entity, stored as short strings so each one is independently addable, searchable, and deletable.

The server exposes this through nine tools: create_entities, create_relations, and add_observations for writing; delete_entities, delete_observations, and delete_relations for removing data (entity deletion cascades to its relations); and read_graph, search_nodes, and open_nodes for reading — the first dumps the entire graph, the second does a text search across entity names, types, and observation content, and the third fetches specific named nodes.

Persistence is intentionally boring: everything is written to a JSON Lines file, memory.jsonl, in the server's working directory by default, or wherever you point the MEMORY_FILE_PATH environment variable. There's no database server to run, which is a large part of why this is the easiest memory server to try first.

A typical Claude Desktop or Claude Code configuration looks like this:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"],
      "env": {
        "MEMORY_FILE_PATH": "/Users/you/.mcp-memory/memory.jsonl"
      }
    }
  }
}

Once it's connected, the practical move is to add a line to your system prompt telling the model to proactively check memory at the start of a conversation and update it when it learns something durable — the server gives the model the capability, but nudging it to actually use that capability consistently is on you. The repository's own documentation suggests exactly this: instructing the assistant to identify entities discussed, connect them to existing knowledge, and store new facts as they come up, rather than waiting to be asked.

Notable third-party memory servers

The reference server is intentionally minimal. If you need semantic search over large amounts of unstructured memory, time-aware facts that can change and be superseded, or memory that's shared across an entire multi-agent system, one of the following is likely a better fit.

Mem0 / OpenMemory. Mem0 is a memory layer for AI applications with its own SDK and hosted platform; OpenMemory MCP is its local-first MCP server, announced by Mem0 as a way to give tools like Claude Desktop, Cursor, and Windsurf a shared, persistent memory that runs entirely on your own infrastructure. Under the hood it stores memories with semantic (vector) indexing in Qdrant alongside relational metadata in Postgres, and exposes MCP tools such as add_memories, search_memory, list_memories, and delete_all_memories. There's also a community Python implementation, mcp-mem0, built directly on the Mem0 SDK as a template for a memory-backed MCP server.

Zep / Graphiti. Graphiti is Zep's open-source framework for building temporal knowledge graphs — the distinguishing feature versus the reference Memory server is that Graphiti tracks how facts change over time and maintains provenance back to the source data, rather than treating the graph as a static snapshot. Its MCP server exposes episode management (adding, retrieving, and deleting episodes of text, chat messages, or JSON) and entity/relationship search, so agents can both log what happened and ask what's true as of a point in time — useful when facts genuinely go stale, like "the project owner" changing hands.

Letta. Letta (formerly MemGPT) treats memory as structured "blocks" attached to an agent — a persona block, a human/context block, and so on — rather than a flat store of facts. The community-maintained Letta MCP Server exposes that model over MCP, with operations to create, list, read, update, and attach memory blocks to running agents, alongside broader agent- and tool-management operations. It's a good fit if your architecture already centers on Letta's stateful agents rather than treating memory as a standalone service.

Basic Memory. Basic Memory takes the opposite bet from vector or graph databases: it's local-first and stores everything as plain Markdown files on disk, with a local SQLite index layered on top purely for speed. Both the AI and the human are meant to read and edit the same files directly, and wikilink-style references between notes let a real knowledge graph emerge from ordinary Markdown rather than a bespoke schema. If you want your agent's memory to be something you can git diff, grep, or read in a text editor without going through a tool call, this is the model to reach for.

Chroma and other vector stores. For teams that already run a vector database like Chroma for RAG, the same store can double as memory: write conversational facts in as documents with embeddings, and use similarity search as the retrieval tool. This isn't a single named product so much as a pattern — several community MCP servers wrap Chroma, Qdrant, or similar stores with add_memory/query_memory-style tools — and it's worth considering when you want memory and document retrieval to share infrastructure rather than run two separate systems.

Comparison

Server	Storage model	Best for	Link
Memory (official reference)	Knowledge graph, persisted as JSONL on disk	Getting started fast, small-to-medium personal or single-agent memory	github.com/modelcontextprotocol/servers
Mem0 / OpenMemory	Vector embeddings (Qdrant) + relational metadata (Postgres)	Local-first semantic recall shared across multiple MCP clients	mem0.ai/blog/introducing-openmemory-mcp
Zep / Graphiti	Temporal knowledge graph with provenance	Facts that change over time and need point-in-time queries	github.com/getzep/graphiti
Letta	Structured memory blocks attached to an agent	Teams already building on Letta's stateful agent runtime	github.com/oculairmedia/Letta-MCP-server
Basic Memory	Markdown files on disk + SQLite index	Human-readable, git-friendly, editable-by-hand memory	github.com/basicmachines-co/basic-memory
Chroma / vector-store pattern	Vector embeddings, general-purpose	Sharing infrastructure with an existing RAG pipeline	trychroma.com

Design considerations before you wire one up

What actually belongs in memory. Not everything worth saying is worth remembering. Durable preferences, decisions, and stable facts about your project belong in memory; the blow-by-blow of a debugging session usually doesn't. If your agent writes an observation for every message, you'll end up with a store that's noisy enough to make retrieval worse, not better — search results get diluted by trivia, and a knowledge graph with a thousand low-value nodes is harder to reason over than one with a hundred good ones. Whatever server you pick, the prompt instructions around when to write matter as much as the tool itself.

Privacy and scope. A memory server that persists indefinitely is also a server that's now holding a growing pile of potentially sensitive information — names, infrastructure details, business decisions — outside the model's normal training-data boundary. Decide early whether memory is scoped per-user, per-project, or global to a machine, and whether it needs encryption at rest or access controls if it's shared across a team. The reference server's local JSONL file has none of this by default; it's your responsibility to add it if the deployment needs it. If you're evaluating any MCP server for production use, it's worth reading our MCP security best practices alongside this.

Memory rot and staleness. Facts change. A project's tech stack gets migrated, a teammate leaves, a decision gets reversed. A memory server with no update or expiry mechanism will happily keep serving you a fact that stopped being true six months ago, and an LLM has no innate skepticism about a tool result — it will treat stale memory as current truth unless you build in some notion of recency or supersession. This is precisely the gap Graphiti's temporal model is aimed at; if you're using a simpler store, you need to periodically prune or have the agent overwrite outdated observations rather than only ever appending.

When memory hurts more than it helps. Memory adds a retrieval step, and retrieval can be wrong. A search that surfaces an irrelevant or outdated memory and gets treated as ground truth is worse than having no memory at all, because it's confidently wrong rather than honestly blank. For short-lived, single-session tasks — a one-off script, a throwaway analysis — the overhead of writing to and querying a memory store is pure cost with no payoff. Memory earns its keep for agents used repeatedly over time by the same user or team, on projects with real continuity. If that's not your usage pattern, skip it.

Conclusion

Memory is one of the clearest cases where moving a capability out of the model and into an MCP server produces a better result than trying to solve it with context-window engineering alone. The official Memory reference server gets you a working knowledge graph in minutes with nothing to deploy, and it's the right starting point for most individual developers. Once you need semantic recall over large volumes of unstructured memory, time-aware facts, or memory that's genuinely shared infrastructure across a team, Mem0/OpenMemory, Zep's Graphiti, Letta, or a vector-store-backed server each solve a more specific version of the problem — pick the storage model that matches how you actually think about the facts you want your agent to keep.