Persistent Memory for MCP Clients: Connected Is Not Captured
Connect Claude and ChatGPT to the same memory server, then ask each one about a decision you saved the day before. Claude runs a search and answers. ChatGPT says it does not have that. Or you get the reverse the next day.
Both results are legitimate. The connection screen promised access to memory tools, and that is all it promised. The gap between those two things is worth understanding before a memory server holds anything that matters.
MCP transports tool calls. Saving is a decision made in the chat.
The Model Context Protocol connects an AI app to external tools. A memory server exposes tools like search, store, and status. The model decides when to call them.
That division explains nearly every confusing thing you will see. A save has to happen, the connection has to point at the vault holding it, and a later search has to actually run. A successful OAuth handshake proves none of those three, which means a green connection with an empty vault behaves exactly like a green connection that works, until you check.
This layer sits next to the native memory Claude and ChatGPT already have. Keep those; the vault is the piece that works across all of them.
Where capture is automatic, and where it is not
On Claude, Claude Cowork, and ChatGPT, memory tool use is model-directed. The model chooses when to search or store, and tool use is not guaranteed on every turn. When a client skips memory on a message, asking it directly to check MemoryRouter is a normal move, not a failure. The tool result shows up in the conversation while you watch.
Claude Code, Codex, and OpenClaw sit on the deterministic side. They install lifecycle hooks, so a completed turn is captured without the model deciding anything. One setup trap lives there: Codex hooks need a MemoryRouter API key at install time in addition to the browser OAuth that powers the explicit tools. Skip the key and you get a quiet half-setup where on-demand lookups work and capture never happens.
Hook capture, model-directed tool calls, and bringing old conversations into a vault are three separate capabilities across every client, and the docs track them per platform.
Run the two-client test before real work goes in
This takes a few minutes, a fresh vault, and one synthetic fact.
- In the first client, ask it to store one harmless fact explicitly: "Please store this in MemoryRouter: Project Lantern ships on Fridays." Watch for the store tool result. A reply that promises to remember, with no tool call behind it, is the model talking, not the server.
- Ask for memory status from the same client. It reports the connection, the vault it is bound to, counts, and the scopes you granted. If the count did not move, the save did not happen.
- Open a second client connected to the same vault. New conversation, nothing pasted. Ask: "What day does Project Lantern ship?" A working path shows a search against the vault and an answer that includes Friday.
- Optional negative control: point a separate connection at a different vault and ask again. It should return nothing. If it answers, you are not looking at the vault you think you are.
The documented failure modes all collapse into those checks: the tool never ran, the scope was missing, or the connection is bound to the wrong vault. The receipt tells you which.
What the connection does not carry
History does not come with it. A connection makes future tool calls possible; it never uploads the chats that came before. Where a supported import exists for old conversations, it is a separate workflow with its own review step. The connector starts from now.
Vaults do not bleed together. One OAuth connection is bound to one vault, chosen when you sign in. The tools accept no vault or project argument, so a model cannot select one, or escape one, by asking. If you need strict isolation between projects or clients, use separate vaults and separate connections. A scope label that appears inside a conversation is a compatibility behavior, not a security boundary.
Deleting is not inherited from writing. The scopes are independent: read, write, reflect, delete. Authorization defaults to read-only, a read-only token is downgraded again at the key layer so a routing mistake cannot widen it, and whole-vault deletion requires its own scope plus an exact confirmation phrase. A connection you approved to save notes cannot erase the vault.
One fit note, because it matters: if local-only is a hard requirement, a local memory server is the honest answer for that constraint. A hosted vault trades that for reach, and reach is the reason to pick one when the same memory has to be available in a second client or on another machine.
What travels when it works
The vault is the unit of continuity. A fact saved while talking to ChatGPT is retrievable from Claude when you are drafting, and a coding agent can pull the same fact once the work moves to the repo, as long as each connection is authorized against that vault and the model runs the search.
The depth travels too. Search supports tier and importance filters for moving from high-level reflections down to raw memories, date search covers time windows, and lineage inspection answers why a reflection exists by walking it back to its sources. Consolidation is not dashboard-only either: tell a connected chat to consolidate your memories and the model you are already talking to runs the reflection pass, with memory status reporting the debt.
One design detail holds the whole story together. The server runs the stateless 2026-07-28 revision of the protocol, so there is no session to lose. Every request describes itself, a restarted client or a third app opening tomorrow reaches the same memories, and older handshake-era clients still negotiate a connection.
Set it up once, verify it once
The endpoint is https://mcp.memoryrouter.ai/mcp. Authentication is OAuth 2.1 with PKCE handled in the browser, so no API key gets pasted into a connector, and read-only is the default scope set. When you sign in, you choose one vault. Everything the connection can see or save lives there.
MemoryRouter's MCP page covers the per-platform setup for Claude, Claude Cowork, ChatGPT, coding agents, and OpenClaw, with capture behavior for each. The MCP documentation covers the ten tools, the scope model, deletion safeguards, and a troubleshooting table for every failure mode above.
Then run the two-client test with a synthetic fact, before real decisions go in. If a client skips memory on a turn, ask it to check directly, so the tool result lands in the conversation where you can see it.
Create your MemoryRouter account, pick one vault, and paste the endpoint into the first client you care about.