iCog iCog·Research
N°05 · Standards · MCP

MCP for Personal AI

How the Model Context Protocol quietly solved cross-vendor memory.

MCP for Personal AI

The protocol that changed the math

In November 2024, Anthropic published a small specification called the Model Context Protocol (MCP). The pitch was modest: a uniform JSON interface for exposing tools, files, and structured context to LLM clients. The first reaction in the broader AI engineering community was muted — another protocol, another spec, file it next to the other ones.

Twelve months later, the math had shifted enough that we should call it. As of Q1 2026, MCP is the de facto standard for AI-to-tool connectivity. The headline numbers:

  • 97 million SDK downloads per month (source: 2026 MCP guide)
  • Donated to the Agentic AI Foundation in December 2025 — a Linux Foundation directed fund co-founded by Anthropic, Block, and OpenAI
  • Native client support in Claude Desktop, Cursor, Continue, Zed, Windsurf, and (incrementally) ChatGPT
  • Hundreds of MCP servers published by individuals and teams, exposing everything from filesystems to GitHub to bespoke private databases

The number that matters more than any of these: the cost of building a cross-vendor memory layer dropped by approximately three orders of magnitude in 2025. What used to require bespoke integration per AI client is now a single MCP server that any compliant client can pick up.

This piece is about what that unlocks for personal AI — and why the walled gardens cannot follow even if they wanted to.

What MCP actually does

A Model Context Protocol server is a small process that exposes:

  • Resources (read-only data the model can ask for — files, database rows, etc.)
  • Tools (callable actions the model can invoke — recall, remember, introspect, etc.)
  • Prompts (templated context the server can offer)

A compliant client (e.g., Claude Desktop with iCog connected) decides when to call which tool, based on the user’s request. The model never has to know what’s behind the call — only the protocol contract.

Three properties make MCP load-bearing for personal AI:

  1. Vendor-neutral. Anthropic shipped it; OpenAI signed onto its governance; Cursor, Continue, Zed, Windsurf all implement it. There is no single owner.
  2. Open. The spec is public, the SDKs are MIT/Apache, the governance is at the Linux Foundation. Forking is possible but unnecessary.
  3. Symmetric. Every MCP-aware client can talk to every MCP-aware server. The set of {clients} × {servers} is open-ended in both dimensions.

That symmetry is the part that quietly solved cross-vendor memory.

The cross-vendor gap, before MCP

In 2023 and most of 2024, “I want my memory to follow me from ChatGPT to Claude to Cursor” was a non-trivial engineering project. You had three options, all bad:

  1. Build a Chrome extension that intercepts requests to each AI’s UI, injects context, and watches responses. Brittle, breaks on every UI redesign, gets banned eventually.
  2. Build a per-client integration for each AI you wanted to support. Maintain it forever as each vendor changes its API. The cost grew linearly with the number of vendors you supported.
  3. Build a wrapper meta-app that proxies all your AI calls through your own UI. This is what Mem and several other “AI workspace” products attempted. It works, but you have to convince the user to abandon ChatGPT/Claude/Cursor and live in your app instead — a much bigger ask than “remember me across the AIs you already use.”

None of these scaled. Hence the assumption, common through mid-2025, that cross-vendor memory was a moonshot — possibly important, almost certainly intractable.

MCP collapsed all three options into a fourth one: expose your memory as an MCP server. Every compliant client speaks to it. You stay in the apps you already use. The integration cost stops scaling with vendors and starts scaling with protocol coverage, which is going to one.

Split composition: a stark closed walled enclosure on the left, an open arched courtyard on the right — same violet light source treated very differently.
Captivity dressed as memory, vs. memory that travels.

Why the walled gardens can’t ship this themselves

Three structural reasons.

1. It is against their interest by design

The walled-garden memory features that shipped in 2025–2026 are not failures. They are doing exactly what they were designed to do: increase switching cost. Every memory ChatGPT learns about you raises the cost of moving to Claude. Every Claude memory raises the cost of moving back. From the platform’s perspective this is rational; from the user’s it is captivity.

A cross-vendor memory product run by a walled garden would undo its own moat. OpenAI is not going to ship “ChatGPT Memory now works in Claude.” Anthropic is not going to ship “Claude memory now works in ChatGPT.” The product is locked-in by definition.

This is the gap. A neutral third party can ship cross-vendor memory because that party has nothing to lose from portability — they have everything to gain.

2. Their product surface assumes the chat UI

ChatGPT Memory works because ChatGPT controls the chat UI. The memory is invisible plumbing that activates inside the chat. There is no clean way to extract that experience and make it work in a third-party client without re-creating the chat UI, which contradicts the very product OpenAI is selling.

A purpose-built cross-vendor memory product (i.e., what iCog is building) treats the chat UI as the venue, not the product. The memory layer is the product; the AI client is just where the conversation happens. That framing only makes sense to a third party.

3. Trust requires neutrality

If your memory is owned by OpenAI, you cannot fully trust it to be neutral about which AI is best for you. The recall function has, at the architectural level, a soft incentive to make ChatGPT look good. This may never manifest as a malicious bias; it does not have to. The mere structural position is enough to make the user’s trust conditional.

A neutral memory layer cannot have that bias because it has no horse in the race. It is in the business of making the user happy with whichever AI they happened to open this morning. That’s the trust position.

What this enables, in product terms

With MCP infrastructure-grade and the walled-garden gap structural, three product moves become tractable in 2026 that were not tractable in 2024:

  1. Bring-your-own-memory. A user buys a personal-memory subscription, adds an MCP server URL to Claude / ChatGPT / Cursor / Zed, and that AI now knows them. No forking the chat UI, no abandoning the AI they already use.

  2. Per-context memory selection. A user can have a work memory layer and a personal memory layer and choose which one any given AI client connects to. The client doesn’t care; it’s just a server config.

  3. Memory verification and inspection. Every recall through an MCP memory server can be logged with the memory ID, the recall score, the tier, and the timestamp. The user can audit what their AI was told. Walled-garden memory features today provide no such transparency.

We expect at least one of these to become a serious consumer product category in 2026–2027. iCog is one of the bets in that direction.

What’s still hard

MCP doesn’t solve everything.

Authentication and authorization across clients. Each MCP-aware client handles auth slightly differently. The user experience of “connect this server to your AI” is still rougher than it needs to be. The protocol allows for OAuth, but the consumer flows are early. Better tooling here is the most-needed near-term improvement.

Bidirectional sync of new memories. When the user tells ChatGPT something new, can the MCP memory server capture it? Today the answer depends on whether the client is calling a remember tool. Some clients do; some don’t. There is room for a convention here that doesn’t yet exist.

Privacy and consent at the server level. A memory server that holds your most private context needs threat modeling that no protocol can hand you. The wedge product wins by being trustworthy here, not by being fast.

Discovery. Today, finding good MCP servers is mostly word-of-mouth. A registry exists; it is not yet load-bearing. The first product that nails server discovery + one-click onboarding will compound fast.

The shape of the bet

If MCP holds — and the Linux Foundation transition strongly suggests it will — then the cross-vendor memory product category is not a niche. It is the default, given enough time. The question is who builds it: a neutral third party (the iCog wager), one of the model labs (structurally hard, see above), or a model-agnostic platform like Cursor or Continue (possible but their product surface points elsewhere).

We think it’s a third party, and we think the wedge is trust + portability + inspectability — the three things the walled gardens cannot ship without contradicting their business model.

Twelve months ago, that bet would have required building the protocol too. The protocol is now built. The bet is on the product.

Sources

§ end