MCP Memory Servers Explained: Persistent Memory for AI Agents

If you've read what MCP is, the mechanics here are short: a client connects to a server, discovers its tools, and calls them. The protocol is deliberately silent on what a server does. A filesystem server exposes file operations; a Postgres server exposes queries; a memory server exposes storing and retrieving things the agent wants to remember.

That's the entire definition. Everything worth discussing is in how different servers fill it in.

What problem it's actually solving

An agent's context window is working memory: large, fast, completely volatile. Three boundaries destroy it, and a memory server is the only thing that crosses all three.

Session end. Tomorrow starts empty, however large the window.
Compaction. A long session summarizes its own history, and summaries keep narrative while dropping specifics. What that costs.
Tool switch. Claude Code and Codex share nothing by default. Unless something outside both holds it.

Note that bigger context windows address the severity of the second and none of the first or third. Capacity is not persistence.

The five designs

“Memory server” covers genuinely different architectures. They're not substitutes, and picking by feature list rather than by design tends to end badly.

1. Conversation memory

Extracts facts from chat automatically. You say something; the system decides it's worth remembering and stores it. Zero effort, which is the appeal, and it captures things you'd never have thought to write down.

The cost is precision. Extraction can't reliably distinguish a decision from a passing thought, or a current fact from one you contradicted two turns later. For personal preferences that's a fine trade. For engineering knowledge, where the agent will act on what it retrieves, a confidently-returned obsolete claim is worse than an empty result.

2. Knowledge graph

Stores entities and relationships. Genuinely powerful for “what depends on this service” style questions, where the answer is a traversal rather than a document.

The cost is schema. Someone has to decide what an entity is and what relationships exist, and real project knowledge is stubbornly unstructured — “we tried three approaches and the second one nearly worked but the provider's rate limit is per account” does not fit a triple.

3. Vector store

Embeds text and retrieves by similarity. Finds things when you don't remember the wording, which is a real advantage over keyword search.

The cost is that similarity is all there is. A vector store has no notion of current versus superseded, no status, no structure. Ask about the queue architecture and you get the March decision and the June reversal, both highly similar, with nothing to say which one is true now.

4. Local file memory

Markdown on your disk, exposed over MCP. Completely private, trivially inspectable, no account, no network. If your constraint is “this data must not leave this machine”, this is the answer and nothing else is.

The cost is reach: one machine, one person. Web clients like ChatGPT can't reach a local process at all, and neither can your laptop when you're on the other one.

5. Curated project memory

Notes written deliberately: decisions, root causes, constraints, rejected approaches. Structured enough to have projects, tags and status; unstructured enough to hold a paragraph of prose.

The cost is the habit. Nothing gets stored unless something decides to store it. In practice that's addressed with a rule in the instruction file, and it turns out to be a feature as much as a cost — deliberate writes are why the store stays high-signal.

The divide that actually matters

Cutting across those five: automatic versus curated. Does the system capture memories by inference, or does something explicitly decide?

	Automatic	Curated
Effort	None	A rule, plus the agent following it
Recall	High — catches what you'd never write down	Lower — only what was deemed durable
Precision	Low — opinions and asides get stored as facts	High — every entry was a decision
Failure mode	Confident retrieval of something stale or never true	A gap: something useful was never written
Human-readable	Often not — fragments, not prose	Yes — a person can read the store
Best for	Preferences, personal context, assistants	Engineering knowledge an agent will act on

The asymmetry in the failure modes is the argument. A missing memory costs you the time to re-derive something. A wrong memory costs you a confident agent acting on a decision you reversed months ago — and you may not notice until it's in production.

Evaluating one

Six questions, roughly in order of how much they'll matter in month six.

Is it project-scoped? Without it, an agent working on service A retrieves service B's constraints. This is the first thing that breaks at multi-project scale.
Does search return little? The point of external memory is keeping context clean. A search that dumps full documents into the window has relocated the bloat, not removed it. Look for snippet-first results with an opt-in for full bodies.
Can it express “this used to be true”? Timestamps, status, revision history. Without a way to mark something superseded, the store gets less trustworthy the longer you use it — which is exactly backwards.
Does it work from every client you use? A remote HTTP server reaches Claude Code, Codex, Cursor, ChatGPT and a teammate's machine. A local one reaches one process.
How do you get the data out? Ask before you put two years into it. “Export as markdown, any plan, immediately” is a very different answer from “contact support”.
What are the isolation and training policies? This is the reasoning behind your codebase. Ours, stated explicitly.

What it looks like connected

Concretely, for Knownbase — a hosted, curated, project-scoped server:

{
  "mcpServers": {
    "knownbase": { "url": "https://knownbase.dev/mcp" }
  }
}

Or, in Claude Code, one command:

claude mcp add --transport http knownbase https://knownbase.dev/mcp

The agent then has search_notes, get_note, get_notes, upsert_note, delete_note, list_projects, list_note_revisions, get_note_revision and a few structural tools. Two things worth knowing about the design:

Search is lean by default. Results are ids, titles, snippets and metadata — not bodies. Finding the right note costs a fraction of accidentally reading ten wrong ones. includeBody:true opts back in.
Updates are partial. upsert_note leaves omitted fields alone, so an agent correcting one tag can't silently blank a body it didn't send.

Authentication is a bearer key or OAuth 2.1 with PKCE, so both static-config clients and interactive connector UIs work against the same URL. Keys can be read-only or restricted to one project.

Making it actually work

The server is the easy half. The habit is the half that decides whether it's useful, and it's one paragraph in your instruction file:

Before starting work on an unfamiliar area, search project memory for
prior decisions, constraints and debugging findings about it.

When you learn something durable — a decision and its reasoning, a
non-obvious root cause, an environment constraint, an approach that
was tried and rejected — save it.

Code lives in git. Store the reasoning here.

And seed it. An empty store helps nobody; ten minutes spent having an agent read your existing instruction file, ADRs and recent commits into notes is the difference between something useful next week and something useful in two months.

FAQ

What is an MCP memory server?

An MCP server whose tools let an agent store and retrieve information that outlives a conversation. From the agent's side it's just tools — typically search, read and write — backed by a store of notes, facts or embeddings.

How is it different from RAG?

RAG retrieves from a corpus that already exists and the agent doesn't write to: your docs, your wiki, your code. A memory server retrieves from a corpus the agent creates while working. The retrieval machinery overlaps almost completely; the difference is authorship, and it changes what's in the store.

Should I run a local or a hosted memory server?

Local if data must never leave the machine — that constraint dominates everything else. Hosted if you use more than one machine, more than one client, or work with anyone else, since a local process is unreachable from a web client and from your other laptop.

Which MCP clients support remote memory servers?

Most current ones: Claude Code, Claude Desktop and Claude.ai, ChatGPT, Codex, Cursor, Windsurf, Zed and a growing set of frameworks. The requirement is support for remote HTTP MCP servers rather than only local stdio ones.

Won't the store fill up with junk?

It will if writes are automatic and unfiltered — that's the main risk of the category. Curated writes with an explicit test for what counts as durable keep the signal high, at the cost of occasionally missing something.

Try a hosted MCP memory server

Project-scoped, lean by default, readable by every MCP client you use. Free plan, no card required.

Create free workspace

MCP memory servers explained: persistent memory for AI agents