Blog
MCP memory servers for teams
Published: September 23, 2026
An MCP memory server gives any MCP client, such as Claude Code, Cursor or Codex, tools to save and search memories between sessions. Most popular ones are built for one person's or one agent's recall. Before a team shares one, ask who can write, what is reviewed before it is served, how contradictions and expiry work, and whether use is counted.
This note maps the main options from their own READMEs and docs, checked on 2026-09-23, then lists the questions that matter once more than one person depends on the answers. It is a map, not a ranking. Several of these tools are good at what they set out to do.
What is an MCP memory server?
The Model Context Protocol lets an agent call tools on an external server. A memory server exposes tools like “add”, “search” and “delete”, and the agent decides when to call them. Because MCP is a shared protocol, the same server can sit behind Claude Code, Cursor, Codex and the Claude or ChatGPT apps.
That last point is why people reach for one. Built in memory is tied to one tool: Claude Code auto memory is machine local, Codex memories live in ~/.codex, Copilot Memory stays inside Copilot. Our comparison of built in agent memory has the details. An MCP server is the obvious way to get one memory across all of them.
Which memory servers work with Claude Code?
Any MCP server works with Claude Code through claude mcp add. These are the ones people ask about most, described by what their own documentation says:
- The reference Memory server (modelcontextprotocol/servers). A local knowledge graph of entities, relations and observations, stored in a JSONL file. Its README describes it as letting “Claude remember information about the user across chats.”
- mem0 (Mem0 MCP server). A hosted server with tools such as
add_memory,search_memories,update_memoryanddelete_all_memories, scoped by user, agent, app or run. The open source project also runs as a library or a self hosted server, which its README suggests for teams. - Basic Memory (basicmachines-co/basic-memory). Local first Markdown files that you and the AI both read and write, with optional cloud sync. Basic Memory Teams adds a shared cloud workspace where, in its words, “anything a teammate writes is immediately available to everyone else and to their AI assistants.”
- claude-mem (thedotmack/claude-mem). A plugin that captures what the agent does through lifecycle hooks, compresses it into summaries in SQLite with Chroma search, and injects relevant context into later sessions. It exposes MCP search tools and supports
<private>tags to keep content out. - Zep and Graphiti (getzep/graphiti). Graphiti is an open source temporal knowledge graph with an MCP server. Each fact has a validity window, and when information changes the old fact is invalidated rather than deleted. Zep is the managed platform built on it.
- Letta (letta-ai/letta). Formerly MemGPT, now a platform for stateful agents whose memory lives with the agent. Letta Cloud keeps an agent's memory, identity and conversations available across computers.
Two things stand out. Graphiti is the one with a built in answer to “this used to be true”: validity windows. Basic Memory Teams and self hosted mem0 are the ones that say “team” out loud.
Can a team share one memory server?
Technically, yes. Point every engineer's agent at the same endpoint and they read and write one store. The question is what that store becomes after a month.
A personal memory is written by an agent on behalf of one person. If it records a wrong fact, one person sees one wrong answer and corrects it. A shared memory is written by every agent on behalf of everyone. If one session records that payment webhooks retry without dedupe, and nothing sits between the write and the read, every agent on the team is served it next. Nobody on the team decided it. An agent inferred it.
That is not a flaw in any one product. It is the difference between memory (what an agent noticed) and team knowledge (what people decided). The second needs a gate, and the questions below are how you check for one. The security version of the same problem has a name: see agent memory poisoning.
What to ask of a memory server for a team
| Question | Why it matters for a team | What a good answer looks like |
|---|---|---|
| Who can write? | Every agent with the endpoint can teach every other agent. | Writes are attributed to a person, and you can limit who or what may write. |
| Is a write reviewed before it is served? | An inferred fact becomes team policy the moment another agent reads it. | New facts are staged; a human, or a policy you set, approves before any agent sees them. |
| What happens on a contradiction? | Two sessions will disagree. Silently keeping the latest is a coin toss. | A conflicting write is held and shown next to the fact it contradicts. |
| When does a fact expire? | Code changes. A fact about a deleted handler keeps getting served. | Facts retire when the thing they describe is gone, and retired facts are archived, not lost. |
| Does it work across tools? | Your team runs Claude Code, Cursor and Codex, not one of them. | One store, reachable from every agent the team uses, with the same answer in each. |
| Can you see what gets used? | Without a count, dead facts accumulate and nobody knows which to cut. | Per fact: how often it was served, and how often an answer cited it. |
| Where does knowledge come from? | Most decisions were made in Slack or a PR review, not in an agent chat. | It reads the places the team already decides, not only what agents write. |
A cite count is evidence, not proof. An agent can follow a fact without citing it. But a fact served a hundred times and cited zero times is a fact to question. Our note on served vs cited explains the split.
Do validity windows solve contradictions?
They solve half of it. Graphiti's approach, per its README, is that when information changes the old fact is invalidated with its history kept, so you can ask what is true now or what was true at any point. That is the right model for facts that change over time: a service moved, an owner changed.
The other half is deciding which statement is true when two arrive. If one session says the webhook handler dedupes and another says the queue consumer does, a timestamp tells you which was written last, not which is right. On a team, that call belongs to whoever owns the payments service. Owners are a team concept, so a store the whole team trusts has to know about them.
Is a memory server the right tool for team decisions?
For your own recall, often yes. A local graph or a Markdown folder that remembers your preferences across tools is a sensible thing to run.
For team decisions, the shape is different. The decision about webhook dedupe from #eng-payments was not made in an agent session. It was argued in a Slack thread and settled in a PR review. A memory server only knows it if someone pastes it in, and then it knows the version that was pasted.
Where Harbor fits
Harbor's MCP server has exactly three tools: harbor_get_knowledge, harbor_record_learning and harbor_revoke_learning. The difference is behind them. Harbor reads Slack, GitHub PR reviews, Notion, Linear and other places your team decides. A write from an agent is staged for review, not live. You set the gate: Manual, Hybrid or Auto, where Hybrid (the default) adds routine conventions and holds anything that contradicts an existing fact, or that cannot be tied to someone in the company, for a human. Served facts are numbered, and Harbor counts per rule how often it was served and how often an answer cited it.
Any MCP client can connect. The knowledge docs cover what gets stored and how it retires, and the quickstart connects your first agent.
Questions
What is the best MCP memory server for Claude Code?
It depends on the job. For personal recall, the reference Memory server, mem0, Basic Memory, claude-mem and Graphiti all work with Claude Code through claude mcp add. For a team, pick on who can write, whether writes are reviewed before they are served, and how contradictions and expiry are handled.
Can a team share one MCP memory server?
Yes, by pointing every agent at the same endpoint. The risk is that any agent's write is served to every other agent. Without a review step, one wrong inference from one session becomes what the whole team's agents are told.
How is team knowledge different from agent memory?
Agent memory is what an agent noticed while working with one person. Team knowledge is what people decided, usually in Slack threads, PR reviews and design docs. It needs an approver, an owner and a way to retire facts when the code changes.
How do memory servers handle contradictions?
It varies. Graphiti gives each fact a validity window and invalidates the old fact when information changes, keeping its history. Deciding which of two conflicting statements is correct is still a judgment a team usually wants a person to make.