The 30-second answer
Claude has four main extension mechanisms, and each one answers a different question. MCP servers give Claude access to systems it cannot reach on its own: databases, browsers, SaaS APIs, internal services. Skills teach Claude to do something your way: procedures, formats, checklists. Subagents let Claude delegate work to a specialized assistant with its own context window and a restricted set of tools. Plugins package any combination of the above so it installs as a single unit.
A quick rule resolves most cases. If the problem is access, you need an MCP server. If the problem is knowledge or process, you need a skill. If the problem is focus, parallelism or permissions, you need a subagent. If the problem is distribution, you need a plugin. Two smaller pieces complete the picture: slash commands (reusable prompts you trigger as /name) and hooks (scripts that run automatically at fixed points, for example right before a tool call).
The rest of this guide covers each mechanism with concrete examples and exact install paths, compares capabilities and security surface, and shows how real setups combine several of them at once.
MCP servers: give Claude access to the outside world
An MCP server is a separate program that exposes tools and data to Claude through the Model Context Protocol, an open standard built on JSON-RPC. It runs outside the model, either as a local process that talks to Claude over stdio or as a remote service over HTTP. When Claude needs to query a Postgres database, drive a browser or read your GitHub issues, it calls the server's tools and receives structured results.
In Claude Code you register one with a single command, for example: claude mcp add github -- npx -y @modelcontextprotocol/server-github. In Claude Desktop you declare it in claude_desktop_config.json, with the command and arguments needed to launch it. Once configured, its tools show up in Claude's tool list and the model decides when to call them.
MCP shines whenever the limiting factor is access: live data, third-party APIs, browser automation, file storage, anything behind a network or a credential. It is also the mechanism with the largest security surface, because the server executes code and often holds secrets, a point we return to in the comparison below. It is the biggest slice of the ecosystem by far: ClaudeWave tracks 2,006 MCP server repositories, more than any other category.
Skills: teach Claude your procedures
A skill is a folder containing a SKILL.md file and optional assets such as scripts, templates or reference documents. The file opens with a short description. Claude Code reads every installed description at session start, then loads the full skill only when a task matches it. That on-demand loading is the point: you can keep dozens of skills installed without paying their token cost until one is actually needed.
Personal skills live under ~/.claude/skills/<name>/SKILL.md and apply to every project. Project skills live in .claude/skills inside the repository and travel with it through version control, so the whole team gets them on clone. There is no server to run and nothing else to configure: create the folder, write the file, start a new session.
Skills shine when the gap is knowledge rather than access: your deploy checklist, the exact structure of your client reports, a database migration procedure, a style guide for commit messages. Because a skill can bundle scripts that Claude runs with its existing tools, it can encode complete workflows, not just writing advice. They are also the largest item category in ClaudeWave's catalog of 12,118 installable items.
Subagents: delegate work without polluting your context
A subagent is a markdown file with YAML frontmatter (a name, a description and an optional list of allowed tools) that defines a specialized assistant. It lives under ~/.claude/agents for personal use, or in .claude/agents inside a project. When Claude Code decides a task matches a subagent's description, it delegates through its Task tool: the subagent runs with its own context window, its own system prompt and only the tools you granted.
Subagents earn their place in three situations. Context hygiene: a code reviewer or a log analyst can read thousands of lines and report back a short summary, keeping your main conversation small. Parallelism: several subagents can investigate different parts of a codebase at the same time. Permissions: a subagent limited to read-only tools cannot edit files no matter what the prompt says, which makes it a safe reviewer.
Note that subagents add no new abilities by themselves. They use the same tools the main agent has, including MCP tools if you grant them, so think of them as a way to reorganize work rather than to extend reach.
Plugins, hooks and slash commands: packaging and control
A plugin is a bundle. It can contain skills, slash commands, hooks and MCP server definitions, and it installs as one unit: /plugin marketplace add owner/repo to register a marketplace, then /plugin install name@marketplace. This is the distribution layer: instead of asking ten teammates to copy four files and edit two configs, you publish one plugin and everyone runs one command.
Hooks are user scripts that run automatically at lifecycle points such as PreToolUse, PostToolUse or SessionStart, configured in ~/.claude/settings.json. They are deterministic: while a skill is an instruction Claude follows, a hook is code the harness executes every single time, whether the model agrees or not. Typical uses: blocking edits to protected files, auto-formatting after every write, loading project state when a session starts.
Slash commands are the simplest piece: prompt files stored under ~/.claude/commands and invoked by typing /name. If you find yourself pasting the same instructions twice a week, a slash command turns them into a one-word trigger. ClaudeWave's catalog indexes slash commands and plugin repositories alongside skills and subagents.
Capabilities, runtime and security surface, compared
On capabilities: MCP servers are the only mechanism that adds abilities Claude does not otherwise have, since they open connections to external systems. Skills shape behavior and can ship scripts, but those scripts run through tools Claude already has. Subagents reorganize work without adding reach. Plugins have whatever capabilities their contents have. Hooks add control, not capability: they decide what is allowed to happen.
On where things run: an MCP server is a separate process, local over stdio or remote over HTTP, and it keeps running between calls. A skill is text loaded into the model's context, plus optional scripts executed in your shell. A subagent runs inside Claude Code with a separate context window. Hooks run as shell scripts with your user's permissions. This matters for cost too: a remote MCP service may have its own pricing, while skills and subagents only consume tokens.
On security, the surfaces are very different. An MCP server executes code, often stores credentials and talks to the network, so it deserves the most scrutiny. ClaudeWave's report The State of MCP Security 2026 audited the MCP servers in its index and found that 29% carry at least one security flag, 20% are unmaintained and 12% ship without a license; some even tell users to install via curl piped into bash. Skills and slash commands are mostly a prompt-injection and bundled-script risk, so read them before installing. Hooks run arbitrary code with your permissions, so treat them like anything else you would execute. Subagents are the most contained, since their tool list bounds what they can do.
How they combine, and how to pick for your case
These mechanisms are complements, not competitors, and mature setups use several at once. A typical team plugin ships a deploy skill with the release checklist, a /release slash command to trigger it, a PreToolUse hook that blocks any command touching production unless a flag file exists, an MCP server for the team's issue tracker, and a code-review subagent restricted to read-only tools. One /plugin install and a new hire has the whole workflow.
A solo data workflow looks different but follows the same logic: a Postgres MCP server provides the access, an analyst subagent runs the heavy queries in its own context, and a reporting skill formats the findings the way your clients expect. The MCP server answers "how does Claude reach the data", the subagent answers "where does the messy work happen", and the skill answers "what does good output look like".
To pick for your own case, start from the gap. Claude cannot reach something: MCP server. Claude does not know your way of doing things: skill. Your context fills up, you want parallel work, or you want hard tool limits: subagent. You repeat the same prompt: slash command. You need a guarantee instead of an instruction: hook. You want to share any of this with others: wrap it in a plugin.
Where to find MCP servers, skills, plugins and subagents
ClaudeWave indexes the whole ecosystem in one place: 4,367 GitHub repositories, from MCP servers (2,006 of them, the largest category) to tools, agents, skills, plugins, hooks and templates, plus an item-level catalog of 12,118 installable items (skills, subagents and slash commands), each with its own page and a 1-command install. Every repository carries a Trust Score from 0 to 100 that combines security heuristics (maintenance, fork ratio, license, owner reputation, README patterns) with an AI review, refreshed every 12 hours. The directory is bilingual, in English and Spanish.
Other directories are worth knowing. mcp.so is the largest MCP-only directory. PulseMCP covers MCP servers with daily updates and estimated-usage data. claudemarketplaces.com lists skills, MCP servers and plugins with editorial summaries. MCP.Directory is another MCP catalog, and skillsmp.com focuses on skills. Each does its slice well; the difference is that none of them covers MCP, skills, subagents, hooks, plugins and templates together, or attaches a security score to every entry.
GitHub awesome lists, such as punkpeye/awesome-mcp-servers, remain a good curated starting point, though they are lists rather than browsable directories: no search facets, no per-item pages, no install commands. Wherever you find a component, the same habit applies before installing: check that it is maintained, check the license, read what it actually executes, and use the Trust Score (or your own review) as a filter rather than installing on name alone.