If you came from the world of ChatGPT plugins, the word "MCP" can sound like the same thing wearing new clothes. It is related, but the difference matters. A plugin is usually tied to one assistant; an MCP server is a standard that many assistants understand. That single difference changes how you build and reuse things. Let me untangle it.
The Short Distinction
A plugin is an integration written for a specific app with a specific shape. An MCP server is an integration written to one open protocol, which any compatible client can then use. Build a plugin and it works in that one place. Build an MCP server and it can show up in Claude, ChatGPT, Cursor, and beyond. This is the "build once, connect many" idea at the heart of this MCP intro.
Where Plugins Still Win
Plugins are not dead. They win when you want deep integration with features only one platform has, or a polished, curated user experience inside a single product. If you only ever target one assistant and never plan to move, a plugin is simpler. MCP is more work up front in exchange for portability, which is only worth it if portability matters to you.
How Tools Compare Under the Hood
| Aspect | MCP server | Plugin |
|---|---|---|
| Standard | Open protocol | App-specific |
| Portability | Works across clients | Locks you to one app |
| Discovery | tools/list | Curated catalog |
| Effort | Once, then reusable | Per platform |
Both end up letting an AI call capabilities. The mechanism of that call is described in the JSON-RPC walkthrough; the difference is all about who can understand the call.
MCP vs a Plain API
The other comparison people make is to a normal REST API. An API is a way to expose data, but an AI still needs to know how to call it, what endpoints exist, and how to parse results. MCP adds the discovery layer: the AI can list and call your tools without reading docs. Confusingly, an MCP server often wraps an API underneath. Reading the tools list is how the AI learns what an API offers.
A Working Example
Look at how IPIPAI does it. Rather than a single plugin for each assistant, it runs one MCP server exposing lookup_ip, rate_ip_node, and more, reachable by any compatible client. The catalog is public at /mcp-tools.json, so the same server serves many assistants. If you want to see how a model turns that list into a real call, this tool-calling example walks through it.
Which Should You Choose?
Ask yourself where your integration must live. One platform, one time, minimal ambition: go plugin. Multiple clients, reusable work, ecosystem reach: go MCP. Many projects now start with MCP precisely because the standard is portable and the setup is no worse in practice. The config guide shows that the setup really is just a small JSON block.
Wrapping Up
Plugins are per-app integrations; MCP servers are portable, standard integrations many assistants understand. The trade-off is simplicity and polish against reach and reuse. Match the choice to your ambition, and both are legitimate. More background on which transport and setup fit your case lives across the IPIPAI blog.