The short version: a plugin is written for one application and works only there. A classic integration is built by two vendors for each other and usually runs in someone's cloud. An MCP server is written once against an open protocol, and any compatible AI client — Claude, ChatGPT, Cursor, VS Code, Zed — can use it without its author doing anything client-specific.
That last property is the entire difference, and it has already changed what the word "plugin" means. On OpenAI's developer site today, a plugin is a bundle that can contain "skills, MCP servers, and optional UI" — the packaging belongs to OpenAI, the mechanism underneath is the open protocol. Checked 13 August 2026.
This article is about what that shift means when you are deciding how to give an assistant access to your own data: who gets to decide the connection exists, where it runs, and what happens when you switch apps. If the protocol itself is new to you, what an MCP server is covers the vocabulary first.
A plugin extends one application from the inside. Slack apps, browser extensions, Figma plugins, the original 2023 ChatGPT plugins. It is written against that application's own extension API, distributed through that application's directory, and it runs under that application's rules. Move to a different app and it does not come with you — there is nothing to move.
A classic integration connects two products to each other. Either the vendors build it natively ("Notion in Slack"), or a middleman does it for both: Zapier, whose own directory advertises 9,949+ connected apps as of 13 August 2026. The unit here is a pair. Somebody has to decide that your particular pair is worth building, and until they do, the pair does not exist.
An MCP server is a program that exposes one source of data or one set of actions — your meeting notes, a database, one folder — through a standard interface. It does not know which assistant will call it, and it does not need to.
The distinction is not about technical elegance. It is about who decides what is possible: a marketplace owner, a pair of business development teams, or the person who owns the data.
With plugins, connecting N data sources to M AI applications takes N×M pieces of work, because each pairing is written separately against a different extension API. Nobody builds N×M of anything. Vendors ration: the big apps get connectors first, the rest wait, and some pairings simply never happen because the business case is too small.
MCP turns that multiplication into addition. Each data source implements the protocol once; each AI application implements the protocol once; every combination then works. That is why the ecosystem grew the way it did — by December 2025, when the protocol changed hands, the announcement cited over 97 million monthly SDK downloads and first-class client support across ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and Visual Studio Code.
The governance detail matters more than it sounds. MCP was donated to the Agentic AI Foundation, a directed fund under the Linux Foundation, on 9 December 2025, co-founded by Anthropic, Block and OpenAI. A plugin API belongs to the company that ships the app, and can be retired by that company — as the 2023 ChatGPT plugin system was. A protocol under neutral stewardship with a public proposal process can still change, but not as a unilateral product decision.
This is the claim most often overstated, so here is the precise version.
What is genuinely written once is the server. The same program, started the same way, serves Claude Desktop and Cursor and VS Code with no per-client code.
What is still per-client is the configuration entry. Each client keeps its MCP settings in its own place, and they are not identical:
| Client | File | Top-level key |
|---|---|---|
| Claude Desktop | claude_desktop_config.json in the app's support folder |
mcpServers |
| Cursor | .cursor/mcp.json in the project, or ~/.cursor/mcp.json |
mcpServers |
| VS Code | .vscode/mcp.json, or mcp.json in the user profile |
servers |
Checked on each vendor's own documentation, 13 August 2026. So the accurate sentence is one implementation, many clients — not one configuration, many clients. What you stop repeating is the expensive part: the implementation, the tool descriptions, the permission model and the vendor's willingness to build it for your app in the first place. Adding a line to a JSON file, or clicking an installer that writes it for you, is the cheap part.
A 2023-style ChatGPT plugin was an HTTPS API by definition. Your data had to be reachable from a vendor's servers, which quietly settled the privacy question before you got to ask it. Zapier-style integrations have the same shape: the data passes through the middleman.
MCP has two transports, and the choice is yours rather than the protocol's. The stdio transport runs the server as a process on your own machine, started by the AI app and shut down when you quit; the Streamable HTTP transport reaches a server running somewhere else. Both speak the same protocol, so a client that supports MCP supports both shapes.
That is the difference that actually changes what is possible: "the assistant can read my local files" is a sentence a plugin architecture cannot produce. It also introduces a distinction worth understanding before you connect anything, because local and cloud MCP servers expose different things to different parties.
| Plugin | Classic integration | MCP server | |
|---|---|---|---|
| Written against | One app's extension API | One pair of products | An open protocol |
| Who decides it exists | The host's marketplace | The two vendors | Whoever owns the data |
| Works in another AI client | No | No | Yes, unchanged |
| Can run on your machine | No | Rarely | Yes, over stdio |
| Triggered by | The host app | A schedule or an event | A model, mid-conversation |
| Controlled by | One company | One company | A Linux Foundation project |
MCP is not a universal replacement, and treating it as one leads to bad architecture.
Unattended automation. An MCP tool runs because a model decided to call it while you were in a conversation. If you need "every weekday at 07:00, copy yesterday's invoices into the accounting sheet", you want a scheduler, and Zapier or a native integration is the correct tool. No amount of protocol makes an idle assistant wake up.
Deterministic workflows. When the same input must produce the same output every time, a model deciding whether to call the tool is a liability rather than a feature.
Distribution to non-technical users. A directory listing with an install button reaches people that a JSON configuration file will not, which is precisely why OpenAI wrapped MCP servers in a plugin format rather than exposing the raw protocol to everyone.
Anything that must work while your laptop is closed. A local stdio server stops when the machine does. That is a feature for privacy and a defect for availability, and only you know which one you are buying.
Speak-Y ships one MCP server inside the app. There is no Speak-Y plugin for Claude, no separate Speak-Y extension for Cursor, and no Speak-Y app in anyone's directory — there is a server, and the clients you use are told where it is. From Settings → Integrations, Install next to a detected client writes that client's configuration file for you, in that client's own format.
Reading is local: search, transcripts, summaries and action items come off the library on your machine, with nothing uploaded for the assistant to read. Commands that change something — tags, speaker names, titles, re-transcription, publishing into a team channel — go through the running app, are declared to the client as data-changing so it asks first, and are logged where you can read them afterwards. The server is free on every plan.
The part that matters for this article is what happens next time a new MCP client appears. Nothing is built for it. It reads the same tool list as everything else, because the work was done against the protocol rather than against a product.
That is the whole argument for MCP over plugins, and it is worth being clear that it is an argument about leverage, not about safety — an open protocol says nothing about what a given server is allowed to do with your data. That question is answered separately, by what makes write access safe, and it is the one to ask before you connect anything at all.
A plugin is written against one application's own extension API and works only inside that application. An MCP server is written against an open protocol, so any compatible client — Claude, ChatGPT, Cursor, VS Code, Zed and others — can use the same server without its author doing extra work per client. The unit of a plugin is an app; the unit of an MCP server is a source of data or actions.
No, they solve different problems. Zapier and comparable platforms run scheduled or event-triggered workflows without anyone present, which is exactly what MCP does not do: an MCP tool runs when a model decides to call it during a conversation. MCP replaces the per-application connector, not the automation platform.
The server is written once and needs no changes, but each client still has to be told about it in its own configuration. Claude Desktop, Cursor and VS Code each keep MCP settings in a different file, and VS Code even uses a different top-level key. What you avoid is a separate implementation per app, not a separate configuration entry.
Not the same, but no longer opposites. The 2023 plugin system was replaced, and on OpenAI's developer site today a plugin is a bundle that can contain skills, an MCP server and optional custom UI. The plugin is now the packaging and distribution layer; MCP is the protocol underneath it.
MCP was donated to the Agentic AI Foundation, a directed fund under the Linux Foundation, on 9 December 2025. The foundation was co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg. Changes go through a public proposal process rather than a single company's roadmap.