Plugins vs MCP

Plugins and MCPs get confused because they overlap. Both extend your agent. Both come from an ecosystem. But they solve different problems. An MCP adds raw tools. A plugin wraps tools PLUS workflows PLUS event handling into a coherent product. Picking the right one matters for how you build, how you distribute, and how your users experience the result.

Head-to-head. The actual distinction.

Read the bottom row as the test: if your thing is "connect to this one service and expose its operations," that's an MCP. If your thing is "turn my agent into a Telegram bot with all the prompts and event handlers that make that work," that's a plugin.

The decision tree.

Three questions. Stop at the first yes.

A real worked example.

Say you want to add "send SMS" to your agent. Here's how each choice plays out:

• As an MCP: a Twilio MCP server exposes a send_sms tool. The agent can call it whenever it decides to. Useful. Not opinionated about when or how.
• As a skill: a /send-sms slash-command with instructions for composing a short, polite message. You type /send-sms 555-1234 and the agent runs your carefully-tuned prompt.
• As a plugin: the whole package. Ships the Twilio MCP, the /send-sms skill, a hook that logs every send to a database, and config defaults (rate limits, default from-number). One install, everything works, nothing else to wire up.

The MCP and skill are the ingredients. The plugin is the dish. You choose based on whether your users want to do the cooking themselves or just sit down and eat.

When to upgrade an MCP to a plugin.

You often start with an MCP, use it for a while, and realize the same supporting pieces keep getting reinvented by each user. That's the signal to graduate it to a plugin.

• Users consistently pair it with specific prompts. → Bake those prompts in as skills inside a plugin.
• Users need event logging or safety hooks. → Add those as hooks inside the plugin.
• Your install instructions start looking like "add this to config, then run this command, then edit this file..." → Collapse the whole thing into one plugin install.
• You're copy-pasting setup instructions into multiple Slack threads. → The friction IS the signal. Ship a plugin.

Rule of thumb: the first time you wish users just had the whole thing working out of the box, that's when you stop shipping an MCP and start shipping a plugin.

Why both exist (and why that's fine).

MCPs are a protocol. Any AI, any client, any future model, can use MCPs. They're the open layer of the ecosystem.

Plugins are a packaging format, specifically for Claude Code today. They're opinionated, convenient, and solve the "I just want this to work" problem in a way that portable primitives can't.

Both are useful for different reasons. Most real production systems end up using both: a few tightly-scoped MCPs for the primitives, a handful of plugins for the complete workflows. Mixing is the right move.