Plugins vs MCP

Plugins and MCPs solve different problems. An MCP adds tools. A plugin bundles tools + skills + hooks into a cohesive product. Picking the right one matters.

Head-to-head

Aspect	MCP	Plugin
What it is	A protocol-speaking program	A package that may include MCPs, skills, hooks
Scope	Narrow, just tools/resources	Broad, whole workflows
Install	Add to config, restart client	One-command install
Portability	Any MCP client	Claude Code-specific (for now)
Contains	Tools, resources, prompts	MCP servers, skills, hooks, config
Best for	Connecting one service	Shipping a complete feature

Decision tree

Q1: Do you just need to expose tools from an existing service?

• Yes → build an MCP server. Ship via npm/PyPI.
• No → go to Q2.

Q2: Do you need to bundle multiple things (MCP + skill + hook)?

• Yes → build a plugin.
• No → go to Q3.

Q3: Do you want a named, slash-invokable workflow (not an auto-used tool)?

• Yes → build a skill (can live standalone or inside a plugin).

Real-world example

Consider a "Send SMS to a number" feature:

• As an MCP: a Twilio MCP server exposes a send_sms tool. Agent can call it whenever it thinks it should. Useful.
• As a skill: a /send-sms skill with instructions for composing a short, polite SMS. User invokes it explicitly.
• As a plugin: bundles the Twilio MCP + the /send-sms skill + a hook that logs every SMS sent to a database.

The plugin is the "product" users install. The MCP and skill are the building blocks.

When to upgrade an MCP to a plugin

• When users consistently pair it with specific prompts → bake them in as skills
• When users need event logging or side effects → add a hook
• When the install story "add this to config, then this, then this" → collapse into one install