Why MCP is not always the best integration choice

MCP has earned its buzz. It gave the AI ecosystem something it badly needed: one standard way for models to talk to tools. MemoryPlugin ships an MCP server, and plenty of our users connect through it every day, so this is not an anti-MCP post. It is a post about a quieter question: once a protocol wins, does that make it the best integration for every product on every surface? I do not think it does, and building an AI memory product has made me more sure of it, not less.

What MCP is, in one minute

MCP is a protocol: a common language for AI clients (Claude, ChatGPT, Cursor, and dozens of others) to call external tools. You wrap your API in tool definitions once, and any MCP client can use it. Want Asana in Claude? Point Claude at an Asana MCP server and the model can create tasks, search projects, and so on. One server, many clients. That is a genuinely good deal, and for developer tools it is often the right one.

A universal integration is the lowest common denominator

Here is the trade nobody puts on the label. A protocol that works everywhere is, by construction, tailored to nowhere. Is an Electron app the best possible app for any platform? Is a React Native app? They are better than no app, and far cheaper than building native for every platform. But when you have the capacity, you can do better for any given surface. MCP has the same shape: better than no integration everywhere, best integration almost nowhere.

For some products that trade is fine. For others, the gap between "works" and "belongs on this surface" is the whole product.

The protocol is a moving target

MCP is young and evolving fast, which is healthy for a spec and painful for anyone shipping against it. Concretely:

Transports keep changing. Remote servers launched on HTTP+SSE, which the 2025-03-26 revision deprecated in favor of Streamable HTTP. Client support fragmented, so serious servers ended up implementing both, including the one that is officially deprecated. The 2026-07-28 release reworks the transport layer again, making the protocol stateless and removing the initialize handshake entirely.
Auth has now changed three times. Simple OAuth gave way to OAuth 2.1 with Dynamic Client Registration, a mechanism many OAuth providers and libraries never supported well. The new spec deprecates DCR in turn, in favor of Client ID Metadata Documents. Each scheme leaves a generation of servers and clients speaking a different dialect.
Clients pick and choose. Every client supports its own subset of the spec, on its own schedule. ChatGPT only gained full MCP support in September 2025, and even now full read/write access lives behind a developer mode toggle on paid plans. When the biggest AI client in the world gates the protocol behind a switch labeled for developers, that tells you who the integration is really for.

None of this is an argument that MCP is badly run. It is an argument that betting your entire product experience on a fast-moving protocol means your users inherit the churn.

Most users are not where MCP is

The deeper problem is distribution. The overwhelming majority of AI usage happens in a browser tab: chatgpt.com, gemini.google.com, claude.ai, perplexity.ai. Those surfaces either do not support MCP at all or tuck it behind settings that normal people will never open. A user who would have to find a server URL, paste it into a connectors menu, enable a beta toggle, and complete an OAuth dance is a user you have lost.

This is why it matters that most AI memory tools are just MCP servers. It is the natural default for a developer team: one integration, broad nominal coverage, demo works in Claude Desktop. But it quietly narrows the audience to people who know what a server URL is. Everyone else, which is to say almost everyone, is left out.

The right integration for each surface

Our answer with MemoryPlugin is to treat MCP as one lane, not the road:

A browser extension for the web apps where people actually talk to AI: ChatGPT, Gemini, Claude, DeepSeek, Grok, and 21+ tools, most of which offer no way to connect an MCP server at all. Install it, sign in, and it works. Your context rides along with your messages, and saving something new is a click in the page, with no cooperation needed from the platform.
A desktop app for what protocols cannot reach at all. Your Claude Code, Codex, and Cursor conversations live in local files on your machine. A remote server has no path to them; an app that syncs those transcripts into your searchable history does.
An MCP server for the clients where MCP is native and excellent: Claude Desktop, Cursor, Windsurf, VS Code, and the rest. This is where the protocol shines, and we meet it there.
Agent skills for coding agents, because a protocol gives an agent tools but not habits. A skill teaches the agent when to recall and what to store; the MCP server underneath just carries the data.

Each surface gets the integration that fits it. The measure is not "does it technically connect" but "does someone who has never heard the word protocol get the value in two minutes."

When MCP is exactly right

To be fair to the protocol: if your users live in MCP-native clients, if your product is fundamentally an API for models, or if you are a small team that must choose one integration, MCP is a fine and often correct choice. One server that reaches every MCP client beats four half-finished custom integrations. The mistake is not choosing MCP. The mistake is stopping there and calling the job done.

The takeaway

Protocols are floors, not ceilings. MCP set a valuable floor: every AI client can now reach every tool that speaks it. But products win on ceilings, and the ceiling for any given surface is an integration built for that surface. Meet your users where they already are, in the browser tab, on their desktop, inside their agent, and let the protocol be one of the ways in rather than the only one.