Plugins vs MCP Servers vs Skills

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 is the claude code extensions comparison we wish had existed twelve months ago. We will walk 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. We once built a full MCP server in Rust to provide a set of code review prompts, only to realise that a few markdown files in .claude/commands/ would have accomplished the same thing in ten minutes. We also spent weeks trying to stretch a skill into doing something that required actual API calls, when an MCP server was the correct answer from the start.

The cost of choosing wrong is not just development time. It is maintenance burden, team confusion, and missed capabilities. This guide will give you a clear framework so you never build the wrong thing.

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.

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

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.

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.

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.

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

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.

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

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.

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. We spent weeks learning this the hard way, building MCP servers when we needed skills and stretching skills when we needed MCP servers.

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.