MCP vs Skills vs Subagents: pick the right one

You hear MCP, then Skill, then Subagent. They sound like the same pitch — “make AI do more” — but pick wrong and you’ll:

• build a whole MCP server just to ship a checklist,
• wire 8 MCPs into Cursor and burn tens of thousands of schema tokens per message,
• or let the agent read 200 files in the main context until the session melts mid-task.

This is a sit-beside-you guide: what to pick, when, with copy-paste examples.

For: people on Cursor / Claude Code / Codex who want a lean setup, not hype.

Core idea: MCP = hammer. Skill = how to drive the nail. Subagent = move noisy work to another room. Don’t forge a hammer out of a checklist.

Related: GitHub repos that help with AI coding.

Three things, three jobs

Remember: you already have shell + file reads. Skills and subagents mostly teach how to use that. MCP opens a door the agent couldn’t reach.

Example 1 · Start with a Skill

Every PR review you repeat: “read the diff, hunt nulls / secrets, three risk bullets.”

Don’t write an MCP. Do create a skill:

.cursor/skills/pr-risk-scan/SKILL.md

---
name: pr-risk-scan
description: >
  Scan PR risk before merge. Use when the user asks to review a PR,
  check risk, or "anything dangerous in this diff?".
---

# PR risk scan

1. Read the diff (prefer logic / auth / billing files).
2. List up to 5 risks: null, secret, migration, race, breaking API.
3. Each risk: `file:line` + one why + one suggested fix.
4. No drive-by refactors. No formatting unrelated files.

In Cursor, skills live under .cursor/skills/<name>/. The agent loads only name + description (~30–50 tokens) until the skill actually runs — progressive disclosure. Fifty skills still beat one fat MCP.

Rule of thumb: you’ve repeated the same procedure ≥ twice → write a skill.

Example 2 · MCP (only when the agent can’t reach)

Inside the repo the agent can grep / git / read files. It cannot query live Postgres, open Linear, or pull Sentry — unless you give it a tool.

That’s MCP.

Example Cursor config (paths vary by Cursor version):

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"]
    }
  }
}

Then layer a skill on top:

---
name: triage-bug
description: Triage a GitHub bug — labels, reproduce steps, suggested owner.
---

# Triage bug

1. Use GitHub MCP to fetch the issue + latest comments.
2. Summarize symptom + minimal reproduce steps.
3. Suggest labels: bug / question / needs-repro.
4. Don’t close the issue. Don’t comment unless the user says post it.

Skill = playbook. MCP = hands on GitHub. Missing either → vague advice, or tools used randomly.

Example 3 · Subagent (when work pollutes the main room)

You say: “read all of apps/api/src and summarize the auth flow.”

In the main chat the agent stuffs hundreds of files into context → later turns get slow, expensive, and forget the original goal.

A subagent = hand the job to a helper; only the summary returns to the main room.

Use when:

• broad audit / exploration,
• long test runs + log parsing,
• research across many files when you only need a 10-line conclusion.

Skip for: one prop change, a typo, a 30-second question.

Decision table (tape it near the monitor)

Answer in order:

1. Can the agent already reach that system?

   • No (live DB, SaaS, internal API) → MCP
   • Yes (files, shell, git in-repo) → step 2

2. Are you repeating the same instructions?

   • Yes → Skill
   • No → step 3

3. Is the job noisy / long enough to spoil main context?

   • Yes → Subagent (optionally with a skill)
   • No → just prompt; don’t over-engineer

Common mistakes

Tokens: right choice = quieter bill

• Skill: descriptions stay cheap; body loads on invoke.
• MCP: tool schemas often load early — a few servers can cost tens of thousands of tokens before you ask anything.
• Subagent: spends its own tokens, but saves the main context (usually worth it).

Practical solo / small-team defaults:

• MCP: GitHub or staging DB — start with one.
• Skills: 3–7 playbooks you actually repeat (review, release, incident, commits…).
• Always-on rules: short Karpathy-style + “don’t commit .env” — not a whole skill pack.

More on mouth/token optimization: AI repos post.

15-minute Cursor setup (do it tonight)

Minutes 0–5 · First skill

1. Create .cursor/skills/ship-check/SKILL.md.
2. Starter content:

---
name: ship-check
description: >
  Pre-merge / pre-deploy checklist.
  Use when the user asks if it's shippable, ready to merge, or pre-deploy.
---

# Ship check

1. Run project lint — report concrete errors.
2. Remind manual check: login + one main happy path.
3. Ask: any migration / env change?
4. Output: ✅ / ⚠️ / ❌ per item — no novel.

3. New chat: “are we ready to ship?” — see if the skill fires.

Minutes 5–10 · MCP only if hands are missing

Ask: does the agent need live GitHub issues or a live DB?

• No → stop. Skills + shell cover a lot.
• Yes → add one MCP; disable unused servers in settings.

Minutes 10–15 · House rules (even if team = you)

Four short lines in .cursor/rules/:

• what the main stack is
• lint before claiming “done”
• never touch secrets / .env
• broad exploration → subagent / explore task

Mini playbook using all three

Scenario: “Payment bug on staging — find the root and draft a Linear ticket.”

1. Subagent / explore: chase webhook + logs (noisy).
2. MCP: (if you have it) create the Linear issue from the summary.
3. Skill incident-notes: 5-line postmortem + reproduce steps.

No Linear MCP? The skill still writes markdown — you paste. Don’t build an MCP on day one just to avoid paste.

Closing

2026 AI tooling feels loud because the names multiply. Underneath it’s three valves:

• Reach a new system → MCP
• Remember how your team works → Skill
• Keep the session mind clean → Subagent

Start with one useful skill. Add MCP only when hands are truly short. Reach for a subagent when the main room is about to fill with smoke.

Get that order right — faster agent, calmer bill, fewer fifth-time explanations.

---

Tonight: write one SKILL.md for the thing you re-explain most this week. Tomorrow you can argue about MCP.