An MCP Memory Server Isn't Enough: Tool Access Is Not Recall Quality

This argument is against our own interest. Memnode is an MCP memory server, and the case here is that giving an agent an MCP memory server does not, by itself, give it good memory. It gives it access to memory. Access and recall quality are different problems, and the recent "MCPs aren't enough" discussion is right to separate them. Here is exactly where the line falls.

What MCP genuinely solves

The Model Context Protocol gave agent memory a clean interface. Instead of hoping the right chunk lands in the prompt, the agent calls explicit tools, memory.recall, memory.set, memory.list_recent, and decides in its own reasoning when to use them. That is a real improvement, for two reasons: the decision to recall is now legible instead of buried in an embedding-similarity black box, and you can swap the storage behind the tool without touching the agent. The Claude Code walkthrough shows the wiring, and the server comparison covers the options.

What MCP does not solve

Here is the trap. A memory.recall("preferences") call still has to return the right memory. If the server behind that tool is similarity search over embedded chunks, you have wrapped the exact wrong-recall problem in a nicer interface. The agent now makes a clean, legible call into a layer that hands back a stale or loosely-related fact a third of the time. A tidy tool boundary over a fuzzy backend is still a fuzzy backend. The failure modes are the same ones in why memory layers recall the wrong thing.

The three things MCP leaves entirely to the backend:

• Provenance. The protocol moves memories around; it says nothing about recording where each came from or how much to trust it. Without that you cannot defend against memory poisoning, and you cannot audit a recall.
• Supersession. Nothing in the tool layer makes a correction overwrite the old fact instead of adding a second competing one. That is a property of the store.
• Recency and workload routing. Whether recall returns the current value or the most similar one depends entirely on what the backend does, not on the fact that it was reached through MCP.

The Letta counterpoint, and its ceiling

Letta (formerly MemGPT) takes a different route: let the model manage its own memory, paging facts in and out like an operating system. It is elegant, and it does make the decisions explicit. But it trades one black box for another. When the model decides what to keep and what to evict, you still cannot answer "why did this memory surface and should I trust it," which is the question that matters for both correctness and security. Self-managed memory is not a substitute for provenance; it is a different thing that still needs it.

What "enough" looks like

Enough is MCP tools on top of a backend that does the three things the protocol leaves out: structured recall with explicit keys, supersession so only the current value is retrievable, and provenance so every recall can be traced and trusted. That is the combination, not the protocol alone, that fixes the "it remembers the wrong thing" complaint. MCP is the right interface. It is the floor, not the ceiling. Build the recall quality underneath it, or you have shipped a clean API over the same old problem.

Sources

• Model Context Protocol specification
• Atlan: agent memory frameworks compared (Letta architecture)