Skills, MCP and subagents, in plain English

You built something that works. Then someone in a Discord told you that you need to "set up your skills properly", "hook up an MCP", and "run it with subagents" — and every explanation you found afterwards assumed you already knew what those were.

Here is the whole thing in one sentence.

Skills change what your AI knows. MCP changes what it can touch. Subagents change who does the work.

That is genuinely it. The rest of this post is what each one looks like in practice, how to tell which one your problem needs, and the two places where picking wrong costs you real money.

You do not need to read code to follow this.

80%

of the 14,300+ builders Lovable surveyed for its 2026 Build Economy report describe themselves as being in non-technical roles. Self-reported, unaudited, and one vendor's own user base. Lovable Build Economy 2026

66%

of developers name AI code that is "almost right, but not quite" as their biggest frustration. Self-reported, ~49,000 respondents. Stack Overflow 2025

The comparison, up front

Two of those three are written in plain English by people who do not code. That is not a simplification for this article — a Skill and a subagent are both literally just a text file with a short header, and we will look at one of each.

First, the thing that explains all three

Every one of these exists because of a single limitation, and once you understand the limitation the three answers stop feeling arbitrary.

Your AI has a context window — a working memory for the current conversation. Everything goes in there: your instructions, the files it opened, the errors it hit, its own previous replies. It is large, but it is finite, and it does not refill.

So this happens:

Step 5 is the experience that makes people say the AI got worse this afternoon. It did not get worse. It got full. Once you see that, the three tools sort themselves:

• Skills stop you re-typing the same instructions into every new session — and they take up almost no room until they are needed.
• MCP stops the agent guessing at things it cannot see, which is what most of those forty file-opens were.
• Subagents do the messy work in a different working memory and hand back only the answer, so the forty files never enter yours.

Skills: the handbook you write once

A Skill is a folder containing a file called SKILL.md. That file has a short header and then instructions, in English, about how you want something done.

The header is two required fields — a name and a description (Anthropic's Agent Skills documentation). The description is the important one, because it is what the AI reads to decide whether this Skill is relevant right now. It has to say both what the Skill does and when to use it.

---
name: deploy-checklist
description: The checks to run before pushing anything live — env vars, database
  rules, error pages. Use whenever the user mentions deploying, shipping, or going live.
---

# Before we deploy

1. Confirm no API keys are in env vars starting with NEXT_PUBLIC_.
2. Confirm row-level security is on for every table with customer data in it.
3. Confirm the 404 and 500 pages actually render.
...

That is a Skill. You wrote it in English, you saved it in a folder, and from now on every session applies it without you asking.

Why it does not clog things up

This is the part worth understanding, because it is why you can have thirty Skills installed and pay almost nothing for the twenty-nine you are not using.

Anthropic calls it progressive disclosure, and describes it as working like a well-organised manual: table of contents first, then the chapter you need, then the appendix only if you go looking (Anthropic Engineering). In numbers, from Anthropic's own documentation:

A hundred tokens is a sentence. So the honest answer to "how many Skills is too many" is: far more than you will write.

When you want one

When you catch yourself typing the same correction for the third time. That is the entire test.

• "Always use British spelling."
• "Never touch the migrations folder."
• "Our buttons are components, don't write raw HTML."

Each of those is a Skill, and writing one takes about four minutes. They live in ~/.claude/skills/ if you want them everywhere, or .claude/skills/ inside a project if they only apply there.

MCP: the keys you hand over

Skills are know-how. They do not, by themselves, let your AI see anything new. That is what MCP is for.

MCP — the Model Context Protocol — is an open standard for connecting AI apps to outside systems. The official documentation describes it as "a USB-C port for AI applications" (modelcontextprotocol.io), and that analogy earns its place: before it, every tool needed its own custom adapter for every AI app. Now there is one shape of plug.

You connect to an MCP server — a small program that sits between your AI and some system. There are servers for Figma, for GitHub, for Stripe, for Postgres, for your file system. It is an open standard rather than an Anthropic feature, so Claude, ChatGPT, VS Code and Cursor all speak it.

A server can offer your AI three kinds of thing (MCP architecture):

• Tools — actions it can take. Create the Stripe refund. Run the query.
• Resources — data it can read. The database schema. This Figma file.
• Prompts — ready-made templates for common requests.

Servers run in one of two places: on your own machine, or remotely over the internet. That distinction is not trivia — it is where the security question lives.

The security question, honestly

Handing an AI a key to your live database is a real decision, and the risk is not the one most people picture. It is not that the model goes rogue. It is that anything your agent reads can contain instructions it might follow. Two named versions of it:

Tool poisoning. A malicious server hides instructions inside the description of its tools — text your AI reads and you never see. A 2026 threat-modelling study across seven MCP clients found this the most prevalent and impactful client-side weakness, with defences varying sharply between clients (arXiv:2603.22489 — a preprint, so strong evidence rather than settled fact).

Indirect prompt injection. The agent fetches a page, a ticket, a pull request title. That content becomes part of what it is reading, and a vulnerable agent may act on instructions buried in it (Unit 42, Palo Alto Networks). Nobody had to break into anything. They only had to get text somewhere your agent would look.

You do not need to become a security engineer. Three habits cover most of it:

1. Install MCP servers the way you would install a browser extension — official publisher, or don't.
2. Give each server the narrowest access that works. A read-only database connection cannot delete your customers, whatever it is talked into.
3. Do not connect a payment or production-database server to a session you leave running unattended. The convenience is small; the blast radius is not.

Subagents: a second pair of hands, with their own desk

A subagent is a separate AI session that your main session can hand a job to. Its defining property is that it has its own context window — its own working memory, its own instructions, and its own restricted set of tools (Claude Code documentation).

Go back to the forty files. With a subagent, the search happens over there. Forty files fill its memory, and what comes back to you is three sentences: here is the file, here is the line, here is why. Your session never sees the other thirty-nine.

Like a Skill, it is a markdown file with a short header.

---
name: code-improver
description: Scans files and suggests improvements. Use after writing or modifying code.
tools: Read, Grep, Glob
model: sonnet
---

You are a code improvement specialist. For each issue, explain the problem,
show the current code, and provide an improved version.

Two lines there are quietly doing a lot of work. tools: Read, Grep, Glob is a list of what it is allowed to do — all three are read-only, so this subagent physically cannot edit a file, whatever it decides. And model: sonnet sends it to a cheaper model than your main session, which matters more than you would think in a moment.

You get the same benefits Anthropic lists for them: keeping exploration out of your main conversation, restricting what a given job can touch, and routing routine work to cheaper models.

What it costs

This is the number to keep. Anthropic's engineering team measured their own systems and reported that agents use about 4× more tokens than a plain chat, and multi-agent systems about 15× more (Anthropic Engineering).

Fifteen times is not a reason to avoid subagents. It is a reason to notice that "just run five agents" is a spending decision, and to check the answer was worth it.

When not to use them

Worth reading twice, because it is the opposite of the advice you will get on social media. The same Anthropic write-up says multi-agent setups are not a good fit for tasks where agents need shared context, where the steps depend heavily on each other, or — stated plainly — for most coding tasks, because there is usually not enough that can genuinely run in parallel.

Where it does pay off is breadth: searching a large codebase, researching several options at once, checking one thing across many places. On Anthropic's internal research evaluation, a lead-plus-subagents setup outperformed a single agent by 90.2% (Anthropic Engineering) — a vendor-reported internal benchmark, on research tasks specifically, so read it as directional rather than as a promise about your app.

So which one do you actually need?

Start from the symptom, not the tool.

That last row is not a joke. Most of what looks like a tooling gap is an instructions gap, and Skills, MCP and subagents will all faithfully amplify a vague request into a vague result.

They are meant to be used together

The three are not competing options. Anthropic describes Skills as complementing MCP servers by teaching agents the workflows that use those tools, and puts the distinction like this: "MCP connects Claude to data; Skills teach Claude what to do with that data" (Skills explained, Anthropic).

A worked example. You want a weekly report on which customers are about to churn.

• MCP connects to your database, so the numbers are real rather than invented.
• A Skill holds your definition of churn, the format you want, and the three things you always check first — so you never explain it twice.
• A subagent pulls and crunches the rows in its own session and hands back the finished summary, leaving your main conversation clean enough to actually discuss what to do about it.

Reach, know-how, hands. Each solving the part the others cannot.

Start here this week

In order, cheapest first.

1. Write one Skill. Find the correction you have typed most often this month. Make a folder in ~/.claude/skills/, put a SKILL.md in it with a name, a description saying when to use it, and your instruction underneath. Four minutes. You can ask your AI to write the file for you, then read it and fix the description — the description is the only part that has to be right.
2. Connect exactly one MCP server, from an official publisher, read-only, for the system you are currently copying and pasting out of by hand.
3. Leave subagents alone until you feel the problem. When a session reliably falls over on long tasks, that is the signal. Not before — at 15× the tokens, they are the one of the three that can quietly cost you money.

The people who get the most out of this are rarely the most technical ones; the 80% at the top of this post matches what we see. Knowing your own process well enough to write it down is the actual skill here. That part you already have.