Skills vs Agents vs MCP: What Each One Is Actually For

Skills, agents, and MCP are not three sizes of the same thing. They answer three different questions: what Claude knows, how Claude delegates, and what Claude can touch. Most people pick wrong because they reach for the heaviest tool first, wiring up an MCP server for something a 40-line SKILL.md would have solved.

Here is the short version. Skills are knowledge. Agents are autonomy. MCP is connectivity. Everything else follows from that.

Skills: knowledge, loaded on demand

A skill is a folder containing a SKILL.md with YAML frontmatter (name, description) and optionally a references/ directory for deeper material. Claude Code reads the description at startup, and loads the full body only when the task matches. That's the whole mechanism, and it's the reason skills scale: fifty skills cost you fifty descriptions in context, not fifty documents.

my-plugin/
  .claude-plugin/plugin.json
  skills/
    pricing-advice/
      SKILL.md
      references/
        deals-2024.md

Skills are the right tool when the thing you want to change is Claude's judgment. House style, a decision framework, how your team names branches, what a good cold email looks like, the postmortem of the last three times you got this wrong. No code runs. Nothing connects to anything. It's a document with a trigger condition.

This is also why skills are the substrate for persona work. When installs.me synthesizes a person from their files and call transcripts, the output is skills: "here is how this person evaluates a deal", "here is how they write", each one a SKILL.md that fires when the topic comes up. Knowledge, not machinery.

Skills are overkill for exactly one thing: nothing. They're the cheapest primitive in the stack. The failure mode runs the other way, writing a vague description ("helps with business stuff") so the skill never triggers, or dumping 8,000 words into the body when 400 words plus a references/ file would load faster and steer better.

Agents: autonomy, at the cost of context

A subagent is a Markdown file with frontmatter (name, description, and optionally a restricted tool list) that Claude Code can dispatch work to. The critical property is context isolation: the subagent runs in its own window, does its thing, and returns a result. Your main conversation only pays for the summary, not the 200 file reads it took to produce it.

That property tells you exactly when agents are the right call:

1. The work is noisy. Searching a large codebase, grinding through logs, reviewing a 3,000-line diff. You want the answer, not the transcript.
2. The work is parallelizable. Three research threads that don't depend on each other can run as three agents at once.
3. You want a constrained persona. An agent with only read tools can review code but never "helpfully" edit it.

And when they're wrong: anything conversational or iterative. An agent can't ask you a follow-up question mid-task, and it can't see what you discussed two messages ago. If the task needs your taste applied in a loop ("no, tighter, more like the second version"), keep it in the main thread. Wrapping a five-second lookup in an agent just adds a dispatch round-trip and a lossy summary.

The common mistake is using an agent where a skill belongs. "Write like me" is not a delegation problem. It's a knowledge problem. An agent that writes like you is just a skill with extra steps and worse feedback loops.

MCP: connectivity, with a standing cost

An MCP server is a separate process (locally, usually stdio; remotely, HTTP) that exposes tools Claude can call: query this database, post to this Slack, read this CRM. It's the only one of the three that can reach systems Claude can't already touch through the shell.

That last clause matters. Claude Code has Bash. If your "integration" is a REST API with a decent CLI or a curl-able endpoint, you may not need MCP at all. A skill that documents the API ("here's the auth header, here's the three endpoints that matter, here's what a good query looks like") plus Bash often beats a bespoke server, and it's one file instead of a running process.

MCP earns its keep when: the connection is stateful (a live database session), the auth dance is complicated (OAuth flows you don't want in your shell history), or the tool surface is rich enough that typed schemas genuinely help. Every MCP server also has a standing cost: its tool definitions sit in context whether or not you use them this session. Ten servers with eight tools each is real estate you're paying for on every single prompt.

The decision table

You want Claude to...	Use	Because
Apply judgment, style, or a framework	Skill	Zero runtime, loads on demand
Follow a repeatable procedure	Skill (or a command for explicit invocation)	Procedures are documents
Grind through noisy work off-thread	Agent	Context isolation
Run three independent tasks at once	Agents	Parallelism
Act with restricted permissions	Agent with a tool allowlist	Enforced, not suggested
Touch a live external system	MCP server	Real connectivity
Call a simple REST API	Skill + Bash first	A server is overhead
Think like a specific person	Skills, plural	Personas are knowledge

They compose

The framing "skills vs agents vs MCP" is slightly dishonest, and the best plugins prove it. A Claude Code plugin ships all four surfaces (skills, commands, hooks, MCP servers) from one marketplace.json, and a well-built one uses skills for the judgment, an MCP server only for the connections that genuinely need one, and leaves agents to the user's discretion.

Start with a skill. Escalate to an agent when the context cost of doing it inline hurts. Escalate to MCP when a document plus Bash genuinely can't reach the system. In practice that ordering resolves 80% of "which one do I build" debates before they start, because most of what people want from Claude isn't more reach or more autonomy. It's better judgment, and judgment ships as Markdown.

Install a person

installs.me turns your files, calendar and calls into a Claude Code plugin that thinks like you. Anyone installs it with two commands:

/plugin marketplace add https://installs.me/lautaro
/plugin install lautaro@lautaro-installs