Agent Memory Over MCP: Options and Trade-offs

Agent memory over MCP means the memory lives in a server and the assistant reads and writes it through tools, rather than in files one client loads on its own. The draw is portability: any MCP client, whether Claude Code, Claude Desktop or Cursor, can use the same memory. The decisions that matter are not about the protocol. They are where the server runs, who can read and change what it stores, whether each change records who made it, and where private data ends up. There are three common shapes: the reference knowledge-graph memory server, a memory store you build yourself, and a shared system of record that already has accounts, roles and a history. For what agent memory is in the first place, see what agent memory is.

Why put memory behind MCP

Built-in memory belongs to one client. Claude Code’s auto memory, for example, is a folder on your machine that other assistants do not read. An MCP server turns memory into a set of tools any client can call. The MCP tools specification↗ (opens in a new tab) calls tools model-controlled: the model decides when to recall and when to store. The same specification says there should always be a person able to deny a tool call, which matters more for memory than for most tools, because a write today becomes context for every session after it.

Option one: the reference memory server

The MCP project’s reference servers repository↗ (opens in a new tab) includes Memory, a knowledge-graph memory server published as @modelcontextprotocol/server-memory. It stores entities, each with a name, a type and a list of observations, and directed relations between them, such as “John_Smith works_at Anthropic”. Its tools create and delete entities, relations and observations, read the whole graph, search nodes by text across names, types and observations, and open nodes by name. The whole graph is also offered as a resource, memory://knowledge-graph, and clients that subscribe are told when it changes.

claude mcp add memory --env MEMORY_FILE_PATH=/home/you/agent-memory.jsonl \
  -- npx -y @modelcontextprotocol/server-memory

It is a good way to see memory-over-MCP working, and its limits are the trade-offs of the approach:

• Who can read it: anyone who can read the JSONL file. By default that file sits in the server’s own directory unless MEMORY_FILE_PATH says otherwise.
• Who can change it: any client connected to that server on that machine. There is no sign-in; a local stdio server runs as your process with your file access.
• Audit: an entity holds a name, a type and observations. Nothing in that shape records who added an observation, from which assistant, or when.
• Sharing: one machine, one file. Sharing it with a colleague means sharing the file.
• Status: the repository describes its servers as reference implementations, meant as educational examples rather than production-ready solutions.

Option two: a memory store you build

The second shape is a server of your own, backed by storage you choose. Anthropic’s memory tool↗ (opens in a new tab) for the Claude API is not MCP, but it is a useful model of the design: it runs client-side, Claude requests operations such as view, create, str_replace, insert, delete and rename on a /memories directory, and your application carries them out against storage you control. The documentation is plain that the safeguards are then yours, and they apply just as well to an MCP memory server:

• Strip sensitive data before a note is written.
• Cap how large a memory file can grow, and page long reads rather than returning everything.
• Delete memory that has not been read in a long time.
• Validate every path, so a name like /memories/../../secrets.env cannot reach files outside the memory store.

A server you build can also be remote, which is what makes memory shareable between people. The MCP authorization specification↗ (opens in a new tab) makes authorization optional, but says servers on HTTP transports should follow it, while stdio servers should take credentials from the environment instead. With sign-in in place, the server knows who each request is from, so it can decide who may read which memories and record who wrote each one. Building and securing one is covered in how to build an MCP server and adding authentication to an MCP server.

Option three: memory in a shared system of record

The third shape puts memory inside a system the team already uses, with members, roles and a history. The assistant’s notes become records like any others: readable by people, correctable by people, and attributed. fenbs does this with AI context, a set of short notes on the board that every connected assistant reads before it starts work. Five MCP tools cover it:

• fenbs_get_context returns the notes for everything, plus one project’s own when you name it.
• fenbs_add_context_note leaves a note for the next assistant, signed with its name. Unless a category is given it is filed as “Learned by an AI assistant”.
• fenbs_list_context_notes lists notes with their ids, project, category, who wrote them and when.
• fenbs_update_context_note changes an out-of-date note instead of adding one that contradicts it, and is recorded in History under the name of whoever made the change.
• fenbs_delete_context_note removes a note that no longer applies. It cannot yet be restored from fenbs, so updating is the safer choice when a note is merely out of date.

fenbs_list_context_notes  project: "api"
fenbs_update_context_note id: 12, body: "Staging resets nightly at 02:00 UTC; re-seed before testing."

Anyone who can see the board can read the notes, on the board’s AI context page or through the tools; adding or changing them needs permission to change tasks. Assistants connect through a browser sign-in that issues hour-long access tokens with refresh, or through a token issued by hand under Settings with a name, scopes and an optional expiry, and revoking ends either. The same notes reach Claude, ChatGPT, Cursor and the other connected clients. The limit is deliberate: these are short plain-text notes meant to be read whole, not a knowledge graph or a document store.

The trade-offs side by side

• Who can read: the reference server, whoever can read the file; your own server, whatever you build; a board, its members.
• Who can change: the reference server, any client on that machine; your own server, whatever you enforce; a board, members whose role allows changing tasks.
• Audit: the reference server records no author; your own server, only what you add; a board, a history of changes with names.
• Sharing across assistants: the reference server, clients on one machine; the other two, any client that can sign in.
• Privacy: the reference server keeps plain text on your disk; your own server keeps it wherever you choose; a hosted board keeps it with the service, so secrets and personal data stay out of it.

Risks that come with any shared memory

Memory is context in waiting. Whatever one session writes, the next reads before it acts, so a mistaken note, or one an assistant was manipulated into writing by something it read, keeps doing harm long after the session that produced it. Four habits limit that:

1. Review memory writes, at least at first. Many clients can ask before each tool call; keep that on for the tools that write memory.
2. Prefer memory where every change has a named author and a date, so a bad note can be traced and removed.
3. Scope it. Notes for one project should not load into another; the less an assistant reads, the less can mislead it.
4. Keep secrets, tokens and customer data out of memory entirely. Anything an assistant reads back can end up in its output.

The broader list of what can go wrong when an assistant connects to your tools is in MCP security risks.