Choosing the Right Tool

Most mistakes happen before any file is written, when someone builds an MCP server where a skill would do, or a subagent where a rule would do. Pick the lightest mechanism that solves the problem.

The five mechanisms at a glance

Mechanism	What it is	Loaded into context	Best for
Rule / memory (.cursor/rules/*.mdc, AGENTS.md, CLAUDE.md)	Standing instructions	Always, or when matching files are open	Conventions that apply to every task: coding style, “never do X”
Skill (SKILL.md folder)	Packaged procedure + reference + scripts	Only the name/description until relevant, then the full body	Repeatable workflows and domain knowledge: “how we write release notes”, “how to fill this PDF form”
Subagent (agents/*.md)	A separate agent with its own prompt, context window, and (in Claude Code) tool allowlist	Its own fresh context; returns a summary	Isolating noisy or parallel work: code search, verification, review
SDK agent (Claude Agent SDK / Cursor SDK)	An agent you run from your own code	Whatever you configure	Automation outside the IDE: CI jobs, bots, scheduled tasks, products
MCP server	A process that exposes tools/resources/prompts over the Model Context Protocol	Tool names and schemas are listed to the model	New capabilities: live data, external APIs, actions the agent can’t otherwise take

Hooks (hooks.json) are a sixth mechanism. They’re deterministic scripts that run on agent events, and they’re the right choice when something must always happen (for example, formatting after every edit or blocking rm -rf) rather than being left to the model.

Decision tree

Does the agent need a capability it doesn't have
(call an API, query a live system, act on an external service)?
├── YES → Is there already an official/trusted MCP server for it?
│         ├── YES → Install it. Optionally add a SKILL that teaches how to use it well.
│         └── NO  → Could a script the agent runs via its shell do it?
│                   ├── YES, and it's only for this repo → SKILL with a scripts/ folder.
│                   └── NO, or it needs auth / reuse across clients → Build an MCP SERVER.
└── NO → The agent has the capability but lacks knowledge or a procedure.
          ├── Applies to every task in this project? → RULE / AGENTS.md
          ├── Must happen deterministically every time? → HOOK
          ├── A workflow or domain knowledge used sometimes? → SKILL
          └── Work that floods the context, runs in parallel, or needs
              a different persona/model/permissions?
              ├── Inside the IDE/CLI session → SUBAGENT
              └── Triggered from code, CI, or a product → SDK AGENT

They combine

The strongest setups layer the mechanisms:

• An MCP server gives access to your ticketing system.
• A skill teaches the triage procedure (“label by component, link duplicates, never close without a reason”) and when to call which tool.
• A subagent runs triage in its own context, so the main conversation only sees the summary.
• An SDK agent runs the same subagent nightly in CI.
• A rule holds the one-line standing policy (“tickets are always written in British English”).

Common anti-patterns

Anti-pattern	Why it hurts	Instead
A 2,000-line always-apply rule	Burns context on every request	Move procedures into skills; keep rules under ~50 lines
An MCP server that just wraps git or ls	The agent already has a shell; you add latency and schemas to context	Use a skill that documents the right commands
One “do everything” subagent	No isolation benefit, and a vague description means poor delegation	Narrow subagents with sharp descriptions
A skill that duplicates what the model already knows	Wastes tokens	Only include what’s specific to you
40 MCP tools with overlapping names	The model picks the wrong one, and tool lists eat context	Fewer, well-named, task-shaped tools (see MCP tool design)
Putting secrets in SKILL.md or mcp.json	They leak into git and context	Environment variables, ${env:NAME}, secret managers

Quick sizing guide

Signal	Lean toward
You’d explain it to a new hire in a page or two	Skill
You’d give a new hire a separate login or tool	MCP server
You’d hand it to a contractor with a brief and ask for a report	Subagent
You’d set it up as a cron job or bot	SDK agent
You’d put it on a poster on the wall	Rule