Jonathon's AI Wiki

Skills vs MCP Servers vs Plugins -- When to Use Which

5 min read

Source: ai-research (web research, 2026-04-11)

Claude Code has three extensibility layers that serve different purposes: Skills (procedural knowledge), MCP servers (external system access), and Plugins (bundled packages). Understanding when to reach for each one — and how they complement each other — is the key to building an effective Claude Code setup without over-engineering it.

The Kitchen Analogy

The clearest mental model:

  • MCP servers = a professional kitchen — they provide tools, ingredients, and access to external resources (databases, APIs, file systems, browsers)
  • Skills = recipes — they encode instructions, methodology, and procedural knowledge for how to accomplish specific tasks
  • Plugins = meal kits — they bundle recipes + ingredients + tools into ready-to-go packages

You need both a kitchen and recipes to cook. Tools without methodology produce inconsistent results. Methodology without tools cannot interact with the real world.

Skills — Procedural Knowledge

Use when: you want Claude to follow a specific methodology, workflow, or set of rules consistently.

  • Markdown files in .claude/commands/ — no infrastructure
  • Encode: coding standards, review processes, deployment checklists, domain-specific workflows
  • No external dependencies — purely instructional
  • Examples:
    • A skill that defines your team’s PR review process
    • A skill that encodes your deployment checklist
    • A skill for writing tests in your project’s specific patterns

Strengths: instant to create, zero maintenance, version-controlled with your code

Limitations: cannot access external systems, cannot execute code on their own

MCP Servers — External Connectivity

Use when: Claude needs to read from or write to an external system.

  • Provide Claude with tools to interact with: GitHub, databases, APIs, browsers, file systems, cloud services
  • Three scope levels:
    • User scope (global) — available in all projects, configured in ~/.claude/
    • Local scope (per-project default) — available in the current project, not shared with team
    • Project scope (shared) — configured in .mcp.json, committed to the repo so the whole team gets it
  • Claude Code uses Tool Search for MCP — only loads tool schemas on demand, achieving 95% context reduction compared to dumping all tool definitions upfront
  • Examples:
    • GitHub MCP for repo operations (PRs, issues, code search)
    • Playwright MCP for browser automation and testing
    • PostgreSQL MCP for database queries

Strengths: connect to anything, strong ecosystem of official and community servers

Limitations: require setup and configuration, add operational complexity, security considerations

Plugins — Bundled Packages

Use when: you want a pre-assembled combination of skills, MCP servers, agents, and hooks.

  • Package format that bundles multiple components together
  • Version-tracked with auto-updates from official marketplaces
  • Handle installation and configuration automatically
  • Examples:
    • A testing plugin that bundles a Playwright MCP server + testing skills + pre-configured hooks
    • A deployment plugin that bundles a cloud provider MCP + deployment workflow skills

Strengths: one-click setup, maintained by publishers, auto-updates

Limitations: less customizable than building from components, dependency on publisher maintenance

Decision Matrix

ScenarioReach for
Enforce a coding standard or review processSkill
Access GitHub, a database, or a browserMCP server
Need a full workflow with tools + methodologyPlugin (or Skill + MCP manually)
Team needs shared external tool accessMCP server (project scope via .mcp.json)
Org needs governed tooling at scalePlugin (via enterprise registry)
Quick personal automationSkill (fastest to create)

Starting Recommendations

For a typical development workflow:

  1. MCP servers (2-3):

    • GitHub MCP (repo operations — highest frequency use case)
    • Filesystem server (file operations outside the project)
    • One domain-specific server (e.g., Playwright for web, PostgreSQL for database-heavy work)

  2. Skills (a few custom):

    • Start with the 5 bundled skills (/batch, /claude-api, /debug, /loop, /simplify)
    • Add one custom skill for your most-repeated workflow
    • Add one official skill if it closes a real gap (e.g., Frontend Design for UI work)

  3. Plugins (as needed):

    • Browse the official registry (101 plugins) when you want a turnkey solution
    • Install only when the bundled components would otherwise require manual assembly

Most Workflows Need Both Skills and MCP

  • A code review workflow needs MCP (to access the PR diff from GitHub) and a skill (to define what “good” looks like for your team)
  • A deployment workflow needs MCP (to interact with the cloud provider) and a skill (to encode the deployment checklist and verification steps)
  • A testing workflow needs MCP (Playwright for browser, test runner for execution) and a skill (to define testing patterns, coverage targets, and failure handling)

The power is in the combination, not in choosing one over the other.

Key Takeaways

  • Skills = how to do it (knowledge, methodology). MCP = what to connect to (tools, data). Plugins = pre-assembled bundles of both
  • Most workflows benefit from Skills + MCP together — methodology without connectivity is inert, connectivity without methodology is chaotic
  • Start small: 5 bundled skills + 2-3 MCP servers covers most development workflows
  • Tool Search keeps MCP context costs low (95% reduction) — do not worry about loading too many MCP servers
  • Use the decision matrix above to pick the right layer for each need

Try It

  1. Audit your current setup: run ls .claude/commands/ to see your active skills, and check .mcp.json for MCP servers
  2. If you have MCP servers but no custom skills: create one skill for your most-repeated workflow (deploy, review, test)
  3. If you have skills but no MCP servers: add GitHub MCP — it is the highest-ROI first server
  4. If assembling skills + MCP manually feels tedious: browse /plugin marketplace for a pre-built bundle
  5. Share your MCP config with the team by committing .mcp.json to the repo (project scope)

Graph View

Backlinks