Originally published at getlockstep.dev.
Your team connects a memory server to Claude Code and Cursor. The agents can now save and search notes across sessions.
A week later, one agent remembers that the payments service uses idempotency keys. Another retrieves an old note saying retries are unsafe. A third finds both, cannot tell which is current, and asks the team again.
The memory server worked. It stored and retrieved text. The team still has a decision problem.
That distinction matters when you compare MCP memory servers. Some are good at personal recall. Some build a graph of people, systems, and facts. Some make Markdown notes available to every coding agent. None automatically turns every remembered sentence into a current, approved team decision.
The short answer
| Best for | Pick | Why |
|---|---|---|
| Small local experiments | MCP reference Memory server | Minimal knowledge graph, easy to inspect, no extra platform |
| Shared human and agent notes | Basic Memory | Plain Markdown, links, search, local or shared cloud workspace |
| Hosted semantic recall across clients | Mem0 MCP | Managed HTTPS service with add, search, update, delete, and event tools |
| Facts and relationships that change over time | Graphiti MCP | Temporal graph with entity, relationship, and hybrid search |
| Approved product and architecture decisions | A decision system exposed through MCP | Ownership, status, rationale, rejected options, and review are the missing layer |
There is no useful universal winner. The right choice depends on whether your team needs a notebook, a search layer, a changing knowledge graph, or a decision record.
What to test before choosing an MCP memory server
Do not start with the longest feature list. Test five things against a real handoff between agents:
- Write path: Can Cursor and Claude Code save context without custom glue?
- Retrieval: Does a fresh session get the right memory from a plain question?
- Scope: Can personal preferences stay separate from team facts and project context?
- Change: When a fact changes, can the system show or remove the stale version?
- Control: Can a human tell which memory is current, who accepted it, and why?
The fifth test is where general memory products often stop. That is fine if you are storing preferences or research notes. It is risky if the memory changes what a team builds.
1. MCP reference Memory server: best for a small local graph
The official reference server stores entities, directed relations, and observations in a local knowledge graph. Its MCP tools create and delete entities or relations, add observations, read the full graph, and search nodes. The graph is also exposed as an MCP resource, so compatible clients can receive updates.
That makes it a good starting point when you want to understand the mechanics without adopting a larger system. A team can represent a service, an owner, a dependency, and a few known facts. The JSONL storage is easy to move or inspect.
The tradeoff is in the word reference. It is deliberately basic. It does not give a team a rich review workflow, semantic ranking, permissions model, or a human-friendly workspace. Its sample prompt is also framed around remembering user information, not governing shared engineering knowledge.
Pick it when: one person or a small team wants a transparent local proof of concept.
Skip it when: several teams need shared access, review, lifecycle, or strong search over a large corpus.
Source: MCP Knowledge Graph Memory Server
2. Basic Memory: best for notes humans and agents both edit
Basic Memory keeps knowledge in plain Markdown and builds a traversable graph from notes and links. Its MCP tools cover writing, search, recent activity, directory browsing, and context building. It can run locally, and its cloud workspace is designed to let teammates and their AI assistants share the same knowledge base.
That shape works well for runbooks, research, system maps, handoff notes, and durable explanations. A person can edit the same source in a normal file or note app instead of treating memory as an invisible database. Export risk is low because the source remains Markdown.
The main judgment is discipline. A shared notebook can hold two conflicting notes as easily as one correct note. Search and links help an agent find information, but they do not decide which sentence is binding. Teams still need conventions for owners, current status, review dates, and superseded notes.
Pick it when: humans need to read and edit the same knowledge that agents retrieve.
Skip it when: you want memory to be fully managed or need a temporal graph that reasons explicitly about changing facts.
Source: Basic Memory repository and documentation
3. Mem0 MCP: best for managed semantic recall across coding clients
Mem0's hosted MCP server connects over HTTPS and supports Claude Code, Cursor, Codex, Windsurf, VS Code, and other MCP clients. Its tools add and search memories, retrieve or update one memory, delete memories and entities, and inspect memory operation events.
That makes Mem0 attractive when a team wants semantic recall without operating a graph database. Client setup is documented, and a real round-trip test makes it easy to check whether one client can save a memory and another can retrieve it.
The tradeoff is control and meaning. A hosted service is another place for company context to live, so security and retention need review. Semantic similarity also does not tell an agent that a result was approved, superseded, or limited to one release. Metadata can help, but the team has to define and enforce it.
Pick it when: managed hosting and cross-client semantic search matter more than file-based ownership.
Skip it when: policy requires local storage, or the primary need is decision status rather than recall.
Source: Mem0 MCP documentation
4. Graphiti MCP: best for facts that change over time
Graphiti is built around a temporal knowledge graph. Its MCP server can add episodes, extract entities and relationships, and search facts or node summaries with semantic and hybrid search. It supports graph backends including FalkorDB and Neo4j, with HTTP and stdio routes for MCP clients.
The temporal model is the differentiator. If service ownership, dependencies, customer state, or operating facts change, a time-aware graph is better suited than a bag of similar text chunks. It can preserve how a fact evolved instead of overwriting every previous statement.
That power adds operational weight. Teams must run the graph stack, configure model providers, decide entity types, and monitor extraction quality. Graphiti's MCP server is also described as experimental in its own repository. It is a stronger fit for teams already sure that temporal graph retrieval solves a real problem.
Pick it when: relationships change often and queries need to understand what was true when.
Skip it when: your main need is a lightweight shared notebook or a first memory experiment.
Source: Graphiti MCP server documentation
A memory server is not automatically a team memory
A tool can retrieve the sentence "we use PostgreSQL advisory locks" and still leave four questions unanswered:
- Was that an idea or an accepted decision?
- Which system and release does it apply to?
- What constraint made the team choose it?
- Has a later decision replaced it?
This is why teams can add more agent memory and still keep re-explaining the same architecture. General memory improves recall. It does not, by itself, establish authority.
If your symptom is broader context loss, see the best tools for AI coding agent context. If you are evaluating the protocol layer, compare the best MCP servers for engineering teams. If agents are reopening settled choices, the more relevant comparison is decision log tools for product and engineering.
How to choose without creating another abandoned system
Run one two-agent test before rollout:
- Ask Cursor to save the reason for a real architecture choice.
- Start a fresh Claude Code session with no copied chat history.
- Ask what the current choice is, why it exists, and what was rejected.
- Change the decision through the team's normal approval path.
- Ask both agents again.
A usable system should return the current answer, preserve the reasoning, identify the owner or source, and avoid presenting the old answer as equally valid. If it only finds both notes, it solved storage and search, not the team handoff.
Where Lockstep fits
Lockstep is for the narrower problem generic memory does not settle: decisions that the whole team and its agents must follow.
It keeps the accepted choice with its rationale, rejected options, owner, and status, then makes that decision available to agents through MCP. Cursor, Claude Code, and the people reviewing their work can use the same current record instead of treating every retrieved note as equally authoritative.
That does not replace all memory. A team may still use Basic Memory for shared notes, Mem0 for recall, or Graphiti for changing relationships. Lockstep is the decision layer alongside them - the place that answers not only "what do we remember?" but "what did we agree to build?"
