← Back to Blog
July 29, 2026 · 5 min read

MCP Memory: How Agents Remember Across Sessions

Short answer: MCP memory means giving an agent persistence through the Model Context Protocol itself, as tools it can call: store this fact, recall that topic. Because MCP is the standard plug between agents and tools, memory delivered as MCP tools works in every client that speaks the protocol, which is exactly what makes it more interesting than another app-specific memory feature.

The term gets used for three different setups, and they are worth separating before you pick one.

The three things people mean by MCP memory

The reference memory server. The MCP project ships an official memory server that stores a knowledge graph (entities, relations, observations) on your machine. You connect it like any other server, and the agent gets create and search tools over that graph. It is a fine way to see the idea working in ten minutes, and an honest preview of the limits: it is local to one machine, unscoped, and maintaining graph hygiene lands on you.

Framework memory exposed over MCP. Dedicated memory services (Mem0, Zep, Letta and friends) increasingly speak MCP too, so the store you wired into your own agents can also be reached by off-the-shelf clients. Powerful if you already live in one of those stacks; a build decision if you do not.

Memory built into the MCP layer itself. The newest pattern, and the one we find structurally interesting: the gateway that already federates your MCP servers also provides the memory tools. No extra server to run, no framework to adopt. Memory becomes a property of the connection layer, present wherever your tools are.

Why the MCP layer is a natural home for memory

Here is the observation the third pattern rests on. Almost everything worth remembering in agent work passes through tool calls.

The agent creates an invoice: the ID comes back through a tool call. It queries the staging database: the name it used is in the call. It files a ticket, sets a config, looks up a customer: call, call, call. The connection layer sees all of it, in structured form, with arguments and results, as a side effect of doing its routing job.

That puts memory next to the stream it needs to capture. A client-side memory feature has to infer what mattered from conversation text. A gateway sits on the structured feed: this tool, these arguments, this result. Explicit remember calls still matter for decisions and preferences (the "we excluded pilot customers, here is why" class of fact), but the plumbing-level facts (IDs, names, results) are already flowing past the one component positioned to keep them.

There is a second, plainer advantage: portability. Memory tools served over MCP are just tools in the list. Claude Desktop sees them, the IDE sees them, any future client sees them. Store tonight in one app, recall tomorrow in another. Memory stops being a feature of a particular chat window and becomes part of your infrastructure, which is where a fact like "the production database is called prod_eu_2" always belonged.

What the tool set looks like

Concretely, gateway-level MCP memory arrives as a handful of tools in the agent's catalog:

  • remember: store a durable fact, ideally with its reason.
  • recall: query stored facts by topic, at session start or mid-task.
  • checkpoint: save the state of the current plan, so a session cut short or a compacted context does not lose the thread.
  • set_goal and get_pending: declare what the multi-step task is, and replay open loops after an interruption.

The verbs are the interface; the discipline is the value. An agent instructed to recall at the start and checkpoint at the end behaves, within a week, noticeably less like a goldfish. The full day-to-day workflow, with a worked example, is in [how to give an AI agent persistent memory](/blog/give-your-ai-agent-persistent-memory).

Honest limits and boundaries

MCP memory is not a magic archive. Three boundaries to respect:

  • It is not RAG. Document knowledge belongs in retrieval over a corpus; memory holds what the agent learned working. Mixing them muddies both, as we argue in [agent memory vs RAG](/blog/agent-memory-vs-rag).
  • It needs scoping. Memory shared across projects or clients is a leak waiting to happen. Per-project and per-client boundaries are a requirement, not a nicety.
  • It is a data store with duties. Remembered facts can be personal data. Export, deletion, and retention need answers, the same as for any database. That is a question to ask every provider, including us.

Where we stand, stated plainly: this pattern is Tulimoa's core product. [Our gateway](/gateway) federates your servers and ships the memory tools above, free on every plan, EU-hosted, in early beta and not self-serve yet. If you want the wider architectural survey before committing to any pattern, the [complete guide to memory layers](/blog/memory-layer-for-ai-agents) compares all three homes for memory without the product lens.

Frequently asked questions

Is there an official MCP memory server?

Yes, the MCP project maintains a reference memory server that stores a local knowledge graph and exposes tools to add and search it. It is a good demonstration and a workable single-machine setup, with the expected limits: local, unscoped, and yours to maintain.

What is the difference between MCP memory and a client's built-in memory?

Reach. A client's memory feature belongs to that one app. Memory served as MCP tools is part of the tool layer, so every MCP-speaking client shares the same store, across machines and apps.

Does MCP memory cost tool calls?

Storing and recalling are tool calls like any other, so a provider could meter them. On Tulimoa's gateway, memory tools are free on every plan; check the metering policy of whatever you use, because a memory layer you hesitate to call is a memory layer that quietly stops being used.

MCP Memory: How Agents Remember Across Sessions · Tulimoa