Compare Plugins vs MCP vs Skills in Claude Code

Prelude

When first building extensions for Claude Code, the same question keeps coming up. Should you build a plugin, write an MCP server, or just create a skill? The documentation explains each one individually, but nothing tells you how to think about all three together. It is easy to build the wrong thing before developing a clear mental model.

The confusion is understandable. All three mechanisms extend what Claude Code can do. All three can be shared with a team. All three live in configuration files or project directories. From the outside, they look like three names for the same concept.

They are not. Each one solves a different problem at a different layer of the system. Once the boundaries are understood, choosing between them becomes obvious.

This guide walks through what each mechanism is, when to reach for it, and how to combine all three for a development workflow that covers every use case you will encounter.

The Problem

Claude Code out of the box is powerful. It reads files, writes code, runs commands, and reasons about your project. But every team has unique needs. You might need Claude to query a private database, enforce a deployment checklist, or interact with an internal API that no one outside your organisation has ever heard of.

The moment you try to extend Claude Code, you face a three-way decision. The plugin system offers a marketplace of pre-built tools. The Model Context Protocol lets you build custom tool servers in any language. And skills let you define slash commands that expand into prompts.

Choosing wrong wastes time. A full MCP server in Rust written to provide a set of code review prompts could have been a few markdown files in .claude/commands/ and ten minutes of work. A skill stretched to perform real API calls is a project doomed before it starts: an MCP server is the correct answer from the beginning.

The cost of choosing wrong is not just development time. It is maintenance burden, team confusion, and missed capabilities. The framework below makes the decision deterministic.

The Journey

What Plugins Are

Plugins are packaged extensions distributed through plugin marketplaces. When you install a plugin, you get a bundle that can include tools, prompts, skills, and even MCP servers. Think of a plugin as a complete package, similar to a VS Code extension or a browser add-on.

You install plugins from within Claude Code using the /install slash command and selecting from available marketplace plugins. You can also browse and manage plugins through the /plugins command inside a Claude Code session.

Once installed, a plugin's capabilities are available in every Claude Code session. If the plugin provides a tool called query_database, Claude can call that tool whenever it determines the tool is relevant to your prompt. If the plugin provides skills, those skills appear as slash commands you can invoke.

Plugins can be installed globally (available in all projects) or locally (available only in a specific project). Enterprise administrators can use managed settings to control which plugins are allowed across the organisation.

The key characteristic of plugins is that someone else built them. You install, configure, and use them. If you need something a marketplace offers, a plugin is the fastest path to getting it. If you are building something for others to use, publishing a plugin is how you distribute it.

What MCP Servers Are

The Model Context Protocol is an open standard for connecting AI models to external data and tools. An MCP server is a program that speaks this protocol and exposes capabilities that Claude Code can use. Unlike plugins, you typically build MCP servers yourself to solve problems specific to your organisation.

MCP servers provide three types of capabilities. Tools are functions that Claude can call, like querying a database or creating a Jira ticket. Resources are data that Claude can read, like documentation files or configuration values. Prompts are templates that guide Claude's behaviour for specific tasks.

An MCP server can run locally over stdio (standard input/output) or remotely over HTTP. The stdio transport is simpler. Your MCP server is a program on your machine, and Claude Code launches it as a child process and communicates through pipes. The HTTP transport is more flexible. Your MCP server runs on a remote host, and Claude Code sends requests over the network.

You configure MCP servers in your settings.json or in your project's .mcp.json file.

{
  "mcpServers": {
    "my-database": {
      "command": "node",
      "args": ["./mcp-servers/database-server.js"],
      "env": {
        "DATABASE_URL": "postgresql://localhost:5432/mydb"
      }
    }
  }
}

The power of MCP servers is that they can be written in any language. Python, TypeScript, Rust, Go. Whatever your team knows best. For a thorough walkthrough of building one from scratch, our guide to building MCP servers in Rust covers the full process. The protocol handles the communication layer, so you focus entirely on business logic.

What Skills Are

Skills are the simplest of the three mechanisms. A skill is a markdown file that defines a slash command. The modern approach is to place skills in the .claude/skills/ directory, where each skill gets its own subdirectory with a SKILL.md file. The older .claude/commands/ directory also works, but .claude/skills/ is the recommended path for new projects. When you type /skill-name in Claude Code, the contents of that file are expanded into a prompt and sent to Claude.

Here is a simple skill that generates a code review.

Review the following file for:
- Security vulnerabilities
- Performance issues
- Code style violations
- Missing error handling

File to review: $ARGUMENTS

Provide actionable suggestions with code examples.

Save that as .claude/skills/review/SKILL.md, and you can invoke it with /review src/auth.rs. The $ARGUMENTS placeholder is replaced with whatever you type after the command name.

Skills require no code. No compilation. No protocol knowledge. You write a markdown file, and it becomes a command. This makes skills the most accessible extension mechanism. Any team member can create or modify them, regardless of programming ability. For teams that include non-developers, our guide on skills for non-technical teams covers how to get everyone involved.

Skills are committed to your project repository, making them available to everyone who works on the project. This turns team conventions into executable commands. Instead of documenting "here is how we write migration files," you create a /migration skill that generates one correctly every time.

For a broader look at how skills fit into team collaboration, our guide on skills and the marketplace covers the full picture. Teams centralising their Claude Code extensions on a shared platform can publish skills, MCP servers, and full plugins from a single workflow.

Quick Comparison

Aspect	Plugins	MCP Servers	Skills
What it is	Packaged extension from marketplace	Protocol-based tool server	Slash command from markdown
Built by	Plugin authors, community	Your team, custom	Anyone on the team
Language	Any (packaged)	Any (Python, TS, Rust, etc.)	Markdown only
Provides	Tools, prompts, skills, MCP servers	Tools, resources, prompts	Prompt templates
Installation	/install in Claude Code	Configure in settings.json	Drop file in .claude/skills/
Distribution	Marketplace	Git repo, internal hosting	Project repository
Code required	No (as consumer)	Yes	No
Best for	Pre-built solutions	Custom integrations	Team workflows
Enterprise control	Managed settings	Managed settings	Project-level

Data sources: Claude Code plugins, Claude Code MCP, Claude Code skills, as of 2026-04. Permalink: systemprompt.io/guides/claude-plugins-vs-mcp-vs-skills#quick-comparison.

Capability Matrix by Extension Type

Capability	Plugins	MCP Servers	Skills
Slash commands	Yes (bundled)	No (uses prompts instead)	Yes (native)
Tools (function calls)	Yes (bundled)	Yes (native)	No
Resources (readable data)	Yes (bundled)	Yes (native)	No
Prompts (reusable templates)	Yes (bundled)	Yes (native)	Yes (native)
Subagents	Yes (bundled)	No	No
Hooks (lifecycle events)	Yes (bundled)	No	No
Bundled MCP servers	Yes	N/A	No
$ARGUMENTS placeholder	Yes (in bundled skills)	No	Yes

Data sources: Claude Code plugins reference, Model Context Protocol specification, Claude Code skills reference, as of 2026-04. Permalink: systemprompt.io/guides/claude-plugins-vs-mcp-vs-skills#capability-matrix-by-extension-type.

Plugins in Detail

The plugin ecosystem is where you start when you have a common need. Before building anything, browse the available plugins. Chances are good that someone has already solved your problem.

Installing a plugin happens inside Claude Code. Use the /install slash command to browse and install from available marketplaces. You can also use /plugins to manage your installed plugins, view their capabilities, and configure them.

Once installed, plugins appear in your configuration and their tools become available to Claude. You can review and manage installed plugins at any time through the /plugins command within a Claude Code session.

Plugin configuration is handled through Claude Code's settings interface. Enterprise teams can use managed settings to define which plugins are approved for the organisation, push default configurations, and block unapproved plugins. This gives you the extensibility of a marketplace without the security risk of uncontrolled tool installation.

The limitation of plugins is that they solve general problems. If you need a tool that queries your company's proprietary API with your specific authentication scheme and your specific data model, you will not find that in the marketplace. That is where MCP servers come in.

MCP Servers in Detail

MCP servers shine when you need Claude to interact with something specific to your organisation. A private database. An internal REST API. A custom deployment pipeline. A proprietary data format.

The protocol is simple. Your server declares what capabilities it has (tools, resources, prompts), and Claude Code discovers them at startup. When Claude decides to use a tool, it sends a JSON request to your server, your server processes it, and sends back a JSON response.

Here is a minimal MCP server in TypeScript that provides a single tool. The example uses the @modelcontextprotocol/sdk package, which is the official TypeScript SDK for building MCP servers.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new McpServer({ name: "ticket-server", version: "1.0.0" });

server.tool("create_ticket", {
  title: { type: "string" },
  priority: { type: "string", enum: ["low", "medium", "high"] }
}, async ({ title, priority }) => {
  const ticket = await createInternalTicket(title, priority);
  return { content: [{ type: "text", text: `Created ticket ${ticket.id}` }] };
});

const transport = new StdioServerTransport();
await server.connect(transport);

The flexibility is enormous. Your MCP server can call any API, read any database, execute any logic. It runs as a separate process, so it can maintain connections, cache data, and manage state independently of Claude Code. Reference implementations exist for every major language, including the TypeScript SDK and Python SDK maintained in the official Model Context Protocol organisation.

For the MCP servers and extensions ecosystem, the standard is evolving rapidly. Remote MCP servers over HTTP open up possibilities like shared team servers, hosted integrations, and centralised tool management.

The trade-off is development effort. You need to write code, handle errors, manage dependencies, and maintain the server over time. For simple prompt-based workflows, that effort is not justified. But for anything involving external data or side effects, MCP servers are the correct choice.

Skills in Detail

Skills occupy a unique niche. They are not tools in the traditional sense. They do not call APIs or return data. They are prompt templates that encode team knowledge into repeatable commands.

The .claude/skills/ directory is your skill library. Each subdirectory contains a SKILL.md file that becomes a slash command.

.claude/skills/
  review/SKILL.md       -> /review
  deploy/SKILL.md       -> /deploy
  migration/SKILL.md    -> /migration
  docs-api/SKILL.md     -> /docs-api
  docs-changelog/SKILL.md -> /docs-changelog

Skills support the $ARGUMENTS variable for user input. They also support multi-line content, code blocks, and any markdown formatting. The entire file contents are injected into the conversation as a prompt.

Here is a more sophisticated skill for generating database migrations.

Generate a database migration for the following change: $ARGUMENTS

Follow these rules:
1. Use the project's migration framework (found in db/migrations/)
2. Include both up and down migrations
3. Use British English in comments
4. Add an index for any new foreign key column
5. Test the migration against the schema in db/schema.sql

Name the migration file with format: YYYYMMDD_HHMMSS_description.sql

The beauty of skills is that they encode institutional knowledge. A new team member does not need to know your migration conventions. They type /migration add user_preferences table with theme and language columns and get a correctly formatted migration every time.

Skills are version controlled with your project. They evolve with your codebase. When your conventions change, you update the skill file. Every team member gets the update on their next pull.

When to Use Plugins

Reach for plugins when the problem is common. If you need GitHub integration, database querying, Jira management, Slack notifications, or any other well-known capability, check the marketplace first.

Plugins are the right choice when you want a solution that is maintained by someone else. The plugin author handles updates, bug fixes, and compatibility with new Claude Code versions. You consume the capability without owning the maintenance burden.

Plugins are also the right choice for enterprise environments where you need control over what tools are available. Managed settings let administrators approve specific plugins and push configurations. This is far easier to govern than a collection of custom MCP servers spread across individual developer machines.

The decision is simple. If the marketplace has what you need and you do not require customisation beyond configuration, install a plugin.

When to Use MCP Servers

Reach for MCP servers when you need custom data access or custom side effects. Any time Claude needs to interact with something unique to your organisation, an MCP server is almost certainly the answer.

Common MCP server use cases include querying internal databases with your specific schema, calling proprietary REST or GraphQL APIs, integrating with internal deployment systems, reading from custom data stores or file formats, and performing operations that require authentication with internal identity systems.

MCP servers are also the right choice when you need fine-grained control over tool behaviour. With an MCP server, you control exactly what data is returned, how errors are handled, what logging occurs, and what rate limits apply. A plugin gives you what the author decided. An MCP server gives you exactly what you build.

The trade-off is clear. MCP servers require development and maintenance effort. If you can solve the problem with a plugin or a skill, do that instead. But when you need real integration with real systems, MCP servers are indispensable.

When to Use Skills

Reach for skills when the problem is about workflow, not data. Skills encode how your team works into commands that anyone can run.

Use skills for code review checklists, PR description templates, documentation generation, migration scaffolding, deployment preparation checklists, commit message formatting, and any other repeatable workflow that benefits from a consistent prompt.

Skills are the right choice when the output is entirely generated by Claude from instructions, not from external data. If Claude needs to query an API to fulfil the request, that is an MCP server problem. If Claude needs a pre-built tool to process data, that is a plugin problem. If Claude just needs to follow a specific pattern that your team has agreed upon, that is a skill.

The overhead is near zero. Creating a skill takes minutes. Modifying it takes seconds. There is no compilation, no deployment, no configuration beyond dropping a file in a directory.

Combining All Three

The real power comes from using all three together. In a typical project setup, plugins handle common integrations, MCP servers cover proprietary systems, and skills encode team workflows.

Here is what a typical configuration looks like in practice.

Plugins handle the ecosystem tools. The GitHub plugin for PR management, a testing plugin for running and analysing test suites, and a documentation plugin for generating API docs from code. These are things every development team needs, and the marketplace versions are better maintained than anything most teams would build themselves.

MCP servers handle custom systems. An MCP server that queries the analytics database with a specific schema and business logic. Another that interfaces with an internal deployment pipeline. A third that provides tools for managing the content management system. These are capabilities that no marketplace plugin could provide because they are unique to each organisation's architecture.

Skills handle conventions. A /deploy-checklist skill walks through pre-deployment verification steps. A /review skill applies specific code review criteria. A /migration skill generates database migrations following naming conventions and patterns. A /sprint-summary skill compiles progress updates in the format the project manager expects.

The three layers do not compete. They complement each other. Plugins give you breadth. MCP servers give you depth. Skills give you consistency.

Layered Extension Architecture

Layer 3: Skills (Team Conventions)
  /review, /deploy, /migration, /sprint-summary

Layer 2: MCP Servers (Custom Integrations)
  analytics-db, deploy-pipeline, content-api

Layer 1: Plugins (Ecosystem Tools)
  @anthropic/github, @testing/jest, @docs/openapi

Model drawn from the layered responsibilities documented in Claude Code plugins and Claude Code skills. Permalink: systemprompt.io/guides/claude-plugins-vs-mcp-vs-skills#layered-extension-architecture.

A Decision Flowchart

When you need to extend Claude Code, walk through these questions in order.

Does the marketplace have what you need? If yes, install the plugin. You are done. This is the fastest path and the lowest maintenance burden.

Does Claude need to access external data or perform side effects? If yes, build an MCP server. You need real code that makes real API calls. No amount of prompt engineering in a skill file will give Claude the ability to query your database.

Is the need about workflow, templates, or team conventions? If yes, create a skill. Drop a markdown file in .claude/skills/ and encode your team's knowledge into a repeatable command.

Is the need complex enough to warrant packaging for distribution? If yes, and you have already built MCP servers and skills that work well together, consider packaging them as a plugin and publishing to the marketplace. This lets other teams benefit from your work.

In text form, the flow looks like this.

Decision Flowchart (ASCII)

Need to extend Claude Code?
  |
  +--> Pre-built solution exists? --> Install Plugin
  |
  +--> Need external data/APIs? --> Build MCP Server
  |
  +--> Need workflow/template? --> Create Skill
  |
  +--> Need to distribute? --> Package as Plugin

Flowchart derived from the decision criteria in Claude Code plugins, Claude Code MCP, and Claude Code skills. Permalink: systemprompt.io/guides/claude-plugins-vs-mcp-vs-skills#decision-flowchart-ascii.

Decision Matrix by Need Type

Your need	First choice	Fallback	Rule of thumb
Install GitHub or Jira integration	Plugin from marketplace	Custom MCP server	Check marketplace first; plugins include bundled MCP servers
Query internal database	MCP server	None	Static data sources fail here; skills cannot issue queries
Enforce code-review checklist	Skill	Plugin (if packaged elsewhere)	Prompt templates alone solve this
Trigger internal deploy pipeline	MCP server	Plugin (if one exists)	Needs side effects, not templates
Share team conventions across repos	Skill in .claude/skills/	Plugin (for distribution beyond team)	Commit to repo, every contributor gets it
Distribute tools to other teams	Plugin package	MCP server repo URL	Plugins are the packaging format for distribution
Call a proprietary REST API with custom auth	MCP server	None	Plugins abstract this away; skills cannot execute HTTP
Generate PR descriptions in a fixed format	Skill	None	Static prompt template, no data fetch needed

Decision criteria synthesised from Claude Code plugins, Claude Code MCP, Claude Code skills, and the Model Context Protocol specification, as of 2026-04. Permalink: systemprompt.io/guides/claude-plugins-vs-mcp-vs-skills#decision-matrix-by-need-type.

Install and Configure Reference

Extension type	Install command	Config file	Discovery command
Plugin	/install (from Claude Code session)	Managed by Claude Code settings	/plugins
MCP server (stdio)	Edit .mcp.json or settings.json	.mcp.json (project) or settings.json (user)	/mcp
MCP server (HTTP)	Edit .mcp.json with URL + auth	.mcp.json	/mcp
Skill	Drop SKILL.md into .claude/skills/<name>/	.claude/skills/<name>/SKILL.md	Type / in prompt; autocompletes

Command reference from Claude Code plugins, Claude Code MCP, and Claude Code skills, as of 2026-04. Permalink: systemprompt.io/guides/claude-plugins-vs-mcp-vs-skills#install-and-configure-reference.

Avoiding Common Mistakes

Teams make the same mistakes repeatedly. Here are the ones to watch for.

Building an MCP server for a prompt template. If your "tool" just returns a fixed string or a template, it should be a skill. MCP servers are for dynamic data, not static prompts.

Using a skill when you need data. If your skill says "look up the latest deployment status," Claude will try to help but it cannot actually query your deployment system through a markdown file. You need an MCP server for that.

Reinventing a plugin. Before building a custom MCP server for GitHub, Jira, Slack, or any other popular service, check the marketplace. Someone has almost certainly built a plugin that handles it, and their version is probably more complete than what you would build in a week.

Ignoring enterprise governance. If you are on an enterprise plan, use managed settings to control plugins and MCP servers. Letting individual developers install arbitrary tools defeats the purpose of having security controls.

Making skills too complex. A skill should be a clear, focused prompt. If your skill file is 500 lines long with conditional logic embedded in the markdown, you have outgrown the skill mechanism. Consider breaking it into multiple skills or moving the logic into an MCP server.

When Extensions Overlap

Edge cases exist where two mechanisms could reasonably solve the same problem. A database query template could live as an MCP server tool or as a skill that generates SQL for Claude to run via Bash. The tiebreaker is maintenance cost and error handling.

If the operation needs connection pooling, retries, or structured error responses, it belongs in an MCP server. The server handles the complexity and returns clean results. If the operation is a static template that Claude fills in and the developer reviews before execution, a skill is simpler and faster to maintain.

For teams evaluating which mechanism to adopt first, the MCP specification covers the protocol's capabilities in detail, while the Claude Code plugin documentation explains the marketplace integration model. Community plugin examples are catalogued in the Anthropic plugins repository on GitHub, which is a useful reference for structure and conventions.

Decision-Making Tips for New Teams

Teams adopting Claude Code extensions for the first time often stall at the decision stage. Three practical rules accelerate the process.

Start with skills. Skills have the lowest cost of being wrong. If a skill turns out to be insufficient, you have lost ten minutes of markdown writing, not a week of server development. Create skills for your three most repeated workflows, use them for a week, and note where they fall short. The shortcomings point directly at where an MCP server would add value.

Build one MCP server before installing plugins. This sounds counterintuitive, since plugins are the easiest to consume. But building a single MCP server, even a minimal one that wraps a single API call, teaches you how tools appear in Claude Code, how tool descriptions affect selection, and how errors propagate. That understanding makes you a better consumer of third-party plugins because you can evaluate whether a plugin's tool design is solid before committing to it.

Audit before you add. Before introducing any new extension, list the tools Claude Code already has access to in the current project by running the /mcp command. If the count exceeds thirty tools, Claude's tool selection accuracy begins to drop. Remove or consolidate tools that overlap before adding new ones. A focused tool surface with twenty well-named tools outperforms a sprawling surface with sixty ambiguous ones.

Match the lifecycle to your team's capacity. MCP servers require someone to own the code, update dependencies, and handle breakages when upstream APIs change. If your team cannot commit to that maintenance, prefer plugins maintained by the community or encode the workflow as a skill that degrades gracefully. The best extension is the one your team will actually keep running six months after the initial setup.

The Lesson

The three extension mechanisms in Claude Code are not interchangeable options. They are layers in an extension architecture, each solving a distinct class of problem.

Plugins are for consumption. You install what others have built, configured through settings, governed by enterprise policy.

MCP servers are for integration. You build bridges between Claude Code and your unique systems, writing real code in whatever language suits your team.

Skills are for convention. You encode team knowledge into markdown files, creating repeatable workflows that require no programming ability to use or modify.

The decision framework is straightforward. Check the marketplace first. If you need external data, build an MCP server. If you need a workflow template, create a skill. If you need to distribute, package as a plugin.

Teams that adopt all three layers report the same outcome. Less time building from scratch, less confusion about which tool to use, and more consistency in how the team interacts with Claude Code.

Conclusion

Understanding the distinction between plugins, MCP servers, and skills is not an academic exercise. It is a practical framework that saves you from building the wrong thing. The lesson is usually learned the hard way, by building MCP servers when a skill would have done the job, or stretching a skill to do work that needed real code.

The taxonomy is simple once you see it. Plugins for pre-built tools from the ecosystem. MCP servers for custom integrations with your systems. Skills for team workflows encoded in markdown. Three layers, three purposes, zero overlap.

Start by auditing your current Claude Code setup. If you are using only one of these mechanisms, you are almost certainly missing capabilities that the other two would provide. Install a few plugins from the marketplace. Build an MCP server for your most-used internal API. Create skills for the five workflows your team repeats most often.

The goal is not to use all three for the sake of completeness. The goal is to use the right mechanism for each problem, so that every extension you build is simple, maintainable, and effective.