Shared Memory Across AI Tools: A Practical MCP Architecture

Switching from Claude Code to Cursor, Codex, or another agent should not mean rebuilding your project context from scratch. But “shared memory” is not simply putting every conversation into one database. The hard problems are scope, authority, correction, and verification: which agent may write, which facts are shared, and how do you know a second tool can actually reconstruct the same context?

The most portable design is a memory layer exposed through MCP. Put durable knowledge in files you can read and edit, then give each MCP-compatible client the same tools. Meshnote takes this approach with a self-hosted, Markdown wiki rather than an embeddings-only black box. It is agent-agnostic: the client changes, while the source of truth stays readable.

Why native memory does not automatically travel

Claude, ChatGPT, and coding tools increasingly offer native memory or project context. These are useful when you stay inside one product: setup is low, and the host can optimize retrieval for its own interface. The trade-off is portability. A preference saved by one product may not be visible to another, and the user may not have a file, diff, or export that explains exactly what was retained.

Local instruction files such as CLAUDE.md, AGENTS.md, or editor rules are more portable, but they are usually tied to a repository or client convention. They also do not provide a consistent read/write API. MCP fills that gap by giving different tools a common protocol for searching, reading, and updating an external knowledge store.

Three viable architectures

These choices are not mutually exclusive. A practical system can keep authoritative decisions in Markdown, use a vector index as a derived accelerator, and reserve native memory for ephemeral preferences. The important rule is that derived indexes must be rebuildable from the authoritative layer.

A working cross-tool setup with Meshnote

Meshnote’s hosted endpoint uses OAuth for interactive connectors. For coding clients that accept a bearer token, create an API key in your Meshnote account and configure the same URL and token in each client. For Claude Code, the configuration is:

{
  "mcpServers": {
    "meshnote": {
      "type": "url",
      "url": "https://meshnote.io/mcp",
      "headers": { "Authorization": "Bearer mnk_YOUR_API_KEY" }
    }
  }
}

Save this in the Claude Code MCP configuration, replace the placeholder, and restart the client. Cursor’s MCP configuration uses the same server URL and header:

{
  "mcpServers": {
    "meshnote": {
      "type": "http",
      "url": "https://meshnote.io/mcp",
      "headers": { "Authorization": "Bearer mnk_YOUR_API_KEY" }
    }
  }
}

Transport labels vary by client version, so use the client’s current MCP settings if it calls the HTTP transport streamableHttp rather than http. Do not paste the API key into a repository. Store it in the client’s secret facility or an environment-backed configuration. Meshnote’s MCP tools let an agent list projects, search the wiki, read pages, write pages, and inspect backlinks. Start with a shared project, not a global bucket.

The memory contract that makes sharing safe

1. Separate scopes. Keep personal preferences, team policy, and project facts in distinct pages or projects. A coding agent should not infer that a personal preference is a production requirement.
2. Record provenance. Include the source, date, confidence, and affected project when writing a decision. “Use PostgreSQL” is less useful than “Use PostgreSQL for the billing service; decided in ADR-014 on 2026-08-12.”
3. Prefer append-plus-correction over silent overwrite. When a fact changes, preserve the old decision in history or mark it superseded. This makes disagreements diagnosable.
4. Write selectively. Save stable constraints and decisions, not every chat turn. Retrieval quality falls when a memory store becomes a transcript landfill.
5. Make the source editable. Humans should be able to correct a page with normal file tools or the wiki UI, without needing the same agent that created it.
6. Define concurrency ownership. If two agents can edit the same page, use small atomic changes, review diffs, and avoid whole-document replacement. For high-conflict state, split pages by concern.

A five-minute interoperability test

Do not accept “shared” because two clients can connect. Run this test with two different tools:

1. In client A, write a project decision with its source and date.
2. In client B, search for the decision without copying the text into the prompt.
3. Correct one detail in B and record why it changed.
4. Ask A to retrieve the corrected fact and identify the previous version.
5. Export or open the underlying page directly and confirm the result is understandable without either client.

This catches the failures that benchmark recall alone misses: wrong tenant or project scope, stale indexes, lost corrections, missing provenance, and vendor lock-in. Current memory benchmarks are useful but should not be overinterpreted. For example, published LoCoMo figures report materially different results across systems and evaluation setups, while LongMemEval tests recall behaviors rather than whether a team can audit or migrate its knowledge. Treat those numbers as workload-specific evidence, not a universal leaderboard.

Choose managed semantic memory when fuzzy retrieval at scale is the bottleneck. Choose a stateful runtime when the agent itself owns durable state. Choose a graph when temporal relationships are central. Choose readable files over MCP when decisions must survive tool changes, be reviewed in Git, or be self-hosted. For many engineering teams, the strongest design is layered: Markdown as authority, search as an index, and native context as a temporary cache.

Start syncing — $8/mo, or choose self-hosted for teams from $10/seat/month.

Related Reading

• Memory for AI Coding Agents: A Cross-Tool Setup That Works
• Vector Memory vs Readable Memory: Choosing the Right Agent Memory
• MCP Memory Server: What to Evaluate Before You Connect One
• How to Give Claude Long-Term Memory Without Losing Control