How to Choose Between Skills, MCP Servers and Plugins

The Extensibility Stack: Three Layers, Not Three Competitors

Your agent needs three things that no single mechanism provides: live connections to your systems, reliable execution of your processes, and a clean way to ship all of it to teammates. That's why the "skills vs. MCP servers" framing that dominates blog posts and forums gets the question wrong from the start.

The practitioners who work with these tools daily converge on the same answer: these are complementary layers, not competitors. As one practitioner guide puts it, "MCPs give your agent capabilities. Skills teach your agent workflows." Another source is even more direct — these models "are often discussed as if they compete with one another. They don't."

The mental model breaks down into three distinct layers:

• MCP servers provide capabilities — live, stateful connectivity to external systems like databases, APIs, and SaaS tools. If your agent needs real-time data or must take actions in an external system, this is the layer that delivers it.
• Skills provide knowledge and workflows — structured instruction packages (a SKILL.md file plus references) that encode your process, domain rules, and conventions. A skill teaches the agent how to do things your way.
• Plugins are distribution bundles — installable packages that wrap skills, agents, hooks, and MCP servers together so a complete setup can be shared and installed as a unit.

A useful analogy attributed to Anthropic: MCP provides the professional kitchen; skills provide the recipes. You need both to cook, and a plugin is the meal kit that packages the two for delivery.

The decisive technical difference between the first two layers is context cost. MCP tool definitions load into your agent's context at session start, whether or not the agent uses them — and with fifty MCP servers, you would have a serious context problem. Skills use progressive disclosure: only the name and description load at startup, roughly 100 tokens per skill, with the full body pulled in only when the agent matches it to the task. Anthropic itself applied this lazy-loading concept to MCP with Tool Search, cutting token overhead by 85% — from around 77,000 tokens to 8,700 for setups with 50+ tools, according to analysis of the announcement.

This cost asymmetry is why the practical recommendation across sources is "start simple, compose later": default to skills for process and CLI tools for one-shot actions, and add an MCP server only when a live, stateful connection is genuinely required.

But knowing which layer to use is the easy half of the decision. The harder question — which skills are safe to install and which actually improve your agent's output — remains unsolved. Published security research found prompt injection in 36% of skills tested, with 1,467 malicious payloads discovered across the ecosystem. That's the gap SkillzBench is being built to close: independent verification, sandboxed benchmarking, and per-agent loadouts so your agent only sees what you've chosen. Skills, proven.

A Decision Framework You Can Actually Use

Every choice you make about extending your AI agent trades off capability against context, security, and maintenance. The good news: the research converges on a decision tree that fits on a napkin.

Start with the question, not the mechanism. Ask what your agent actually needs, and the answer usually falls out cleanly:

• Live data or actions in an external system? You need MCP — a stateful connection to a real system the agent must read from or write to.
• A process, domain rules, or expertise? You need a Skill — instructions that teach the agent *how* your team works.
• A simple, one-shot action? Use the CLI directly. No wrapper required.
• Need to distribute a bundle of skills, agents, hooks, and MCP servers together? That is a Plugin — the distribution layer, not a fourth capability type.

As one practitioner guide puts it: MCP gives the agent a capability; a skill gives the agent knowledge. If you can answer the question "does the agent need to reach a system or know something?" you are 90% done.

Default to "start simple, compose later." Multiple sources recommend beginning with skills plus the CLI and adding MCP only when a live connection is genuinely needed — often wrapping the MCP server in a skill that describes how to use it. The reason is context economics: skills load at roughly 100 tokens each at startup via progressive disclosure, while MCP tool definitions sit in context from session start whether or not they are used. "With fifty MCP servers you would have a serious context problem," as the same guide warns. Anthropic's own Tool Search feature cut MCP token overhead by 85% — from roughly 77,000 tokens to 8,700 for a 50-tool setup — precisely because upfront loading was so costly.

Watch for two common pitfalls. First, rebuilding an integration inside a skill: if your skill's scripts start implementing authentication, retries, and paging for a big API, you are writing a bad MCP server in disguise. Second, connecting MCP servers "just in case" — every connected server expands your attack surface for capability you are not using.

And whichever path you choose, verify what you install. Snyk's ToxicSkills research found prompt injection in 36% of skills tested, and a "malicious skill is a prompt injection you installed yourself." That is why SkillzBench is building independent verification — commit-SHA pinning, security scanning, and sandboxed Lift benchmarking — so you can see whether a skill actually helps before it touches your agents.

Skills, proven. Join the waitlist at skillzbench.com to hear when benchmarking opens up.

The Catch: Every Extension Is a Supply-Chain Risk

Every extension you bolt onto an agent widens its attack surface — and the research on this is unambiguous. Choosing between skills, MCP servers, and plugins is the easy part. Knowing whether what you installed is safe, and whether it actually helps, is the problem nobody has solved.

The numbers are sobering. Snyk's ToxicSkills research found prompt injection in 36% of skills tested, plus 1,467 malicious payloads circulating across the skills ecosystem. As one practitioner bluntly put it, "a malicious skill is a prompt injection you installed yourself" — you invited it in, gave it context, and told your agent to trust it.

Worse, the tools meant to catch this have known structural limits. The SkillCloak research tested eight skill scanners against 1,613 in-the-wild malicious skills and found evasion rates that "approached total," using techniques like self-extracting packing. The researchers' conclusion is worth internalizing: static analysis of a skill package cannot tell you what that package will assemble at runtime — that is a ceiling, not a bug.

And it is not just skills. Ten documented attacks on Claude Code between September 2025 and September 2026 targeted the machinery around the model — config files, approval dialogs, MCP tool descriptions, plugin pins, and skill packages. None required a jailbreak. The pattern extends across the ecosystem:

• Agentjacking achieved an 85% success rate across Claude Code, Cursor, and Codex, with 2,388 organizations found carrying injectable Sentry DSNs.
• ToolLeak succeeded on 19 of 25 agent/LLM pairs tested, and achieved remote code execution on every single pair.
• The Miasma worm disabled 73 Microsoft repositories in a single 105-second sweep.

The uncomfortable takeaway: the extension mechanism you choose matters less than the supply chain behind it. As security researchers put it, every file and every message that reaches the agent before a human looks at it is a source of danger. Snyk's own guidance is to treat skills the way you would treat any third-party code you run in your environment — advice most teams installing skills from public repositories currently ignore.

This is the gap SkillzBench is being built to close: independent verification that pins every skill version to a commit SHA, security-scans it, and then actually benchmarks it in a sandbox — with and without the skill — to measure whether it lifts performance at all. Because a skill that is merely safe but useless is its own quiet failure.

Skills, proven.

How to Choose With Confidence: Verify, Benchmark, Equip

Knowing which mechanism to use is the easy part — knowing whether a specific skill is safe and actually helps is the unsolved problem. Snyk's ToxicSkills research found prompt injection in 36% of skills tested and 1,467 malicious payloads across the ecosystem, and security researchers have shown that skill scanners are structurally bypassable — "static analysis of a skill package cannot tell you what that package will assemble at runtime."

That's the trust gap. As one practitioner puts it, treat skills the way you would treat any third-party code you run in your environment — but most teams have no way to do that systematically. What's missing is independent verification and measurement, not more opinions.

SkillzBench is being built to close that gap. The idea is simple: before you equip a skill, you should be able to answer three questions — is it safe, is it legal to use, and does it actually make the agent better?

Here's what SkillzBench is building and will offer at launch:

• Verification you can pin down — every skill version pinned to a specific commit SHA, then validated, license-checked, and security-scanned, so "which version did you test?" always has an answer.
• Sandboxed Lift benchmarking — each skill tested with the same model, with and without the skill installed, publishing the Lift in percentage points rather than a vibe-based rating.
• A 0–100 trust score built from security, quality, license, maintenance, and community signals — kept strictly separate from money, which never touches scores.
• One MCP server plus per-agent loadouts, so you toggle skills and tools per agent and the agent only sees what you chose.
• Continuous tracking of upstream changes, with re-scans, re-benchmarks, and notifications when a skill you rely on moves.

The security stakes justify the rigor. Ten documented attacks on Claude Code targeted the machinery around the model — config files, plugin pins, skill packages — and none required a jailbreak. A compromised skill isn't an edge case; it's a prompt injection you installed yourself.

Launch scope starts with instruction-only skills (SKILL.md plus text references), with script-bearing skills listed link-out only — a deliberate, honest boundary given what the research says about runtime assembly. SkillzBench is pre-launch and actively being built; the waitlist is open, and the benchmark results will follow.

Choosing between skills, MCP servers, and plugins is a solved problem. Proving your skills are safe and worth their tokens — that's what's coming. Skills, proven.

Your Next Steps: Building a Safe Agent Extension Strategy

Choosing between skills, MCP servers, and plugins is the easy part — the hard part is knowing that what you installed is safe and actually helps. Here is a practical strategy you can put in place this week, grounded in the decision framework practitioners have converged on.

Step 1: Audit your current MCP servers for context bloat. Every MCP server you connect loads its tool definitions into context at session start, whether or not you use them. One practitioner measured a 35x difference in token usage between CLI and MCP approaches for the same task, and warns that "with fifty MCP servers you would have a serious context problem." Disconnect anything you connected "just in case."

Step 2: Default to skills + CLI, and add MCP only for stateful connections. The three-question test is simple: live data or actions in an external system means MCP; a process or domain knowledge the agent must follow means a skill; a one-shot action means the CLI. When you do need an MCP server, wrap it in a skill that describes how to use it — the skill teaches the workflow, the server provides the capability.

Step 3: Treat skills like third-party code running in your environment. This is not paranoia. Snyk's ToxicSkills research found prompt injection in 36% of skills tested and 1,467 malicious payloads across the ecosystem. Worse, security research on skill scanners shows static analysis is structurally bypassable — a scan alone cannot tell you what a package assembles at runtime. As one researcher put it, a malicious skill is a prompt injection you installed yourself.

Your implementation checklist:

• Inventory every connected MCP server and disconnect any not used for live, stateful access.
• Write skills for repeatable workflows first; reach for MCP only when the CLI cannot hold state.
• Wrap each MCP server in a SKILL.md describing when and how the agent should call it.
• Review every third-party skill before installation the same way you review a dependency.
• Re-verify skills on every version change, since upstream updates can change behavior.

That last item is where most teams hit a wall: there is no independent way to know whether a skill actually improves agent performance or quietly introduces risk. This is exactly the problem SkillzBench is building against — pinning every skill version to a commit SHA, security-scanning and license-checking it, and benchmarking each one in a sandbox with the same model, with and without the skill, so you can see the Lift in performance before you trust it. The Equip MCP server will then let you toggle verified skills and tools per agent, so each agent sees only what you chose for it.

If you want verified, benchmarked skills and per-agent loadouts in your workflow the day they ship, join the waitlist at skillzbench.com and get notified when the platform goes live.

Skills, proven.