Use a knowledge-graph store when
You want a small, curated set of facts the assistant treats as authoritative — conventions, ownership, standing constraints. Deliberate writing is a feature here, not a cost.
MCP memory servers, compared honestly
Search "MCP memory server" and you get dozens of results that sound identical. They are not. Three different things are wearing the same label, and picking the wrong kind is why people conclude memory servers do not work.
Three kinds, not one category
Knowledge-graph stores
The assistant writes entities and relations, and reads them back. The reference server-memory is this. Excellent for durable facts you state deliberately. Empty until someone writes to it, and it only ever contains what an agent chose to record.
Note-takers
The assistant writes prose summaries at the end of a session and searches them later. Cheaper than storing transcripts and better than nothing. The summary is lossy in the direction that matters: it keeps conclusions and drops the reasoning.
Session indexes
Something indexes the transcripts your tools already wrote to disk. Nothing is recorded deliberately, because the recording already happened. This is the category chat-recall is in.
The question that separates them
What does it know on day one?
A knowledge-graph store and a note-taker both start empty. They become useful after weeks of disciplined writing, which means their value depends on a habit the user has to keep. That is a real cost, and it is why so many get installed and abandoned.
A session index starts with everything you already did. The first search returns months of work, because the transcripts were on disk before the tool existed.
The second question: whose sessions?
Almost every memory server is scoped to the tool it runs inside. Memory written from Claude Code is readable from Claude Code. If you also use Codex, or Cursor, or Gemini CLI, each keeps its own — which is the specific problem people describe when they say their assistant "forgets" after switching.
Reading several tools' formats is unglamorous work: different directories, different file shapes, different ideas of what a session is. It is also the only way one memory spans all of them.
Where each one wins
Use a session index when
The thing you keep losing is what you already did: the approach you rejected, the command that worked, the decision made six weeks ago in a different tool.
Use both, honestly
They answer different questions and do not conflict. chat-recall ships a knowledge graph alongside the index for exactly this reason — deliberate facts and recovered history are not substitutes.
Use neither when
You work in one tool, on one repo, in sessions that finish the same day. claude --continue covers it and costs nothing. See what it does not do.
What to actually check before installing any of them
- Does it read what already exists, or does it start empty?
- How many tools does it span? One is the common answer.
- Where does the data go? Transcripts contain pasted credentials and client code. Ask what leaves the machine, and whether you can run it yourself.
- Can the assistant search it itself, or must you paste results in? A memory you have to operate by hand is a search box, not a memory.
The honest limits of the one we build
A session index cannot recover reasoning that was never written down. If you decided something in your head and typed only the result, no tool gets it back. It is also only as good as the transcripts — a tool that writes nothing to disk cannot be indexed, and the search is keyword-based, so it finds what was said rather than what was meant.