Skills vs agents vs MCP: don't build an AI maintenance job

Skills, sub-agents, MCP servers and hooks solve different problems in a coding agent, but they often get added as one bundle of features. To sort them, choose the smallest mechanism that solves the problem you have. Sometimes that is a prompt, or nothing at all.

Not everything needs an AI agent. AI coding tools change faster than the words we use for them. So skills, agents, MCP, hooks, rules and prompts get talked about as if they were interchangeable. They’re not.

This is part 3 of a series. Part 1 set up the project around the agent, and Part 2 ran one task from investigation to verification. Claude Code is the worked example, because its docs compare these pieces side by side. The tool behaviour here comes from each tool’s official docs, last verified on 4 October 2026; none of it was tested for this post.

Choose the smallest mechanism that solves the problem

Start from the problem. Each mechanism answers one kind of problem, and the first row that fits is usually the right one:

Part 1 had a short version of this table. This one adds the two answers people skip: a plain prompt, and nothing.

Four pairs that get mixed up

Skill or sub-agent: a workflow, or a separate worker

A skill is a workflow the main agent follows. A sub-agent is a separate worker with its own context window and tools, which does one job and hands back the result. Claude Code’s features overview gives each one a line. “Skills are reusable content you can load into any context.” “Subagents are isolated workers that run separately from your main conversation.”

Take a pull request review. If every pull request gets the same steps, that is a workflow:

Every pull request
  → read the diff
  → check conventions
  → run the tests
  → review security
  → write a report

Same workflow every time: that’s a skill. Code review, a release checklist, a security audit, writing documentation, a migration and a testing workflow all fit the same way.

A sub-agent is for a different shape of work, for example:

Main agent: implements the change
  ├── security reviewer (own context)
  └── test reviewer (own context)

Use a sub-agent when the job benefits from its own context or its own tool limits. Claude Code’s sub-agents docs list three cases. The task produces verbose output you don’t need in the main conversation. You want to restrict its tools. Or the work is self-contained and can return a summary. The same page says to stay in the main conversation when “Multiple phases share significant context, such as planning, implementation, and testing”, or when “You’re making a quick, targeted change”.

Don’t create an agent just because you can. And the two can work together: in Claude Code a sub-agent can preload skills, and a skill can run in its own isolated context.

Sub-agent or MCP server: who does the work, or what it can reach

A sub-agent answers “who should do this work?”. An MCP server answers “how does the agent reach this outside system or its data?”. MCP (Model Context Protocol) is an open standard, and its architecture docs describe a server as “A program that provides context to MCP clients”. It offers tools, data and prompt templates, and the agent decides when to use them. So an MCP server isn’t another agent.

Reach for MCP when the agent needs a system it can’t see: GitHub, a database, an issue tracker, a documentation system or an internal tool. Claude Code’s own trigger is a good test: “You keep copying data from a browser tab Claude can’t see”. But if a simple CLI already solves it, use the CLI. Part 1 has why a CLI is often the leaner choice.

Skill or hook: a request, or a guarantee

A skill says “here’s how you should do this workflow”, and the agent interprets it. A hook says “run this action at this point in the session”, and it runs every time its event happens. Claude Code’s features overview says a hook “Always fires on its event; the trigger is guaranteed”, while with a skill “Claude interprets the instructions; outcome can vary”.

Instructions tell the agent what it should do. Hooks make sure something happens. The same Claude Code page: “An instruction like ‘never edit .env’ in CLAUDE.md or a skill is a request, not a guarantee. A PreToolUse hook that blocks the edit is enforcement.”

Timing matters. A hook that runs after an edit can run the formatter or a check and report back. Examples are PostToolUse in Claude Code and afterFileEdit in Cursor. But by then the edit has already happened. To stop an action, you need a hook that runs before the tool call; the table further down names it for each agent. Good hook jobs: a formatter after each edit, blocking dangerous commands, validating a file, a lifecycle check before the agent finishes.

A hook always runs, but its result isn’t always fixed. Claude Code also has prompt-based and agent-based hooks that ask a model to decide.

Prompt or skill: once, or every time

“Review this PR for security” is a prompt. “Here is our complete security review workflow” is a skill. The prompt is fine for a one-off. When you paste the same steps again and again, write them down once. Claude Code’s features overview gives the trigger: “You paste the same playbook or multi-step procedure into chat for the third time”. GitHub Copilot’s CLI feature comparison says to use a skill when you want “A repeatable set of instructions or functionality to be available for a type of task”. Part 5 of this series goes deeper into writing skills you can reuse.

One review task, grown a step at a time

Here’s a made-up example: a team building a Business Central extension in AL wants every pull request reviewed for security and architecture. It is not from a real project. Each mechanism arrives only when a problem asks for it.

1. Ask each time               → a prompt
2. Same steps on every PR      → a skill
3. Needs an independent review → a security sub-agent
4. Needs PR or work item data  → an MCP server or a CLI
5. Must pass on every PR       → a CI check, or a hook

Step 1 is a prompt: “Review this pull request for security and architecture.” For the first few reviews, that’s enough.

Step 2 comes when the steps repeat: review the AL code, check the team’s conventions, inspect permissions, check the tests, summarise the findings. That list is a skill.

Step 3 is a security sub-agent, and only if the review needs an independent context, for example a reviewer that isn’t the agent that wrote the code.

Step 4 is access. If the review needs pull request threads or work items from Azure DevOps or GitHub, connect them. GitHub has the gh CLI. Azure DevOps has a CLI extension and an official MCP server, both in the Azure DevOps CLI docs. One limit from that page: “The Azure DevOps CLI extension works only with Azure DevOps Services (cloud).”

Step 5 is a check that must pass on every pull request, such as the build and the tests. That belongs in CI, which runs whoever opened the pull request, or in a hook if it must run inside the agent’s session.

Each step is added because the one before it stopped being enough.

The over-engineering trap: an AI maintenance job

Picture a small project that adds everything at once: an agent for every role, a skill for every task, a few MCP servers and a hook on every event. Each piece looked sensible on the day it was added. Together, they overlap, and every one of them needs updating when the project changes.

You didn’t build an AI engineering system. You built an AI maintenance job.

The agent pays too. Claude Code’s docs on context costs start with “Every feature you add consumes some of Claude’s context.” Too much of it “can also add noise that makes Claude less effective”. Skills may not trigger correctly, and when their descriptions overlap, Claude “may load the wrong skill or miss one that would help”.

Anthropic’s features overview says it in one line: “You don’t need to configure everything up front.” If the benefit is unclear, do nothing.

Where skills, sub-agents, MCP and hooks live in six coding agents

The ideas are the same across tools; the folders and the triggers differ. Each row says where a piece lives in the project and what happens when it runs. Most tools also have personal locations in your home folder.

Every row comes from the linked docs, last verified on 4 October 2026; none was tested for this post.

The folders overlap more than you’d expect. Codex, Cursor, Copilot, Gemini CLI and Antigravity all read .agents/skills. Copilot and Cursor also read .claude/skills, and Cursor reads .claude/agents/ and .codex/agents/ too. So one skill folder can serve a team that uses several agents.

A prompt that audits before it adds

Use this prompt on an existing repository before you add any skill, agent, MCP server or hook. If your agent has a plan or read-only mode (Part 2 explains why it helps), run it there.

Prompt: audit before you add

Analyse this repository and identify where AI-assisted
development workflows could benefit from:

1. Project instructions/rules
2. Reusable skills
3. Specialised agents
4. MCP or external tool integrations
5. Deterministic hooks or automation

Do not create anything yet. Never print, expose or commit secret values.

Do not recommend a Skill, Agent, MCP integration or Hook
merely because it is technically possible.

For each recommendation, explain:

- What problem it solves
- Why the current approach is insufficient
- Why this mechanism is appropriate
- What simpler alternative could solve it
- What complexity it introduces
- Whether it should be added now or later

For every recommendation, estimate:

- frequency of the problem
- complexity added
- maintenance cost
- security implications
- simpler alternatives
- expected benefit

Prefer the smallest solution that solves the problem.
If the benefit is unclear, recommend doing nothing.

Then give me a proposed architecture and wait for approval.

The “smallest solution” and “doing nothing” lines let the agent recommend nothing at all.

Quick answers

What is the difference between skills, agents and MCP?

Skills, sub-agents and MCP (Model Context Protocol) solve different problems. A skill is a reusable workflow, a sub-agent is a separate worker with its own context, and MCP connects the agent to outside systems and data.

Can one skill folder work in several coding agents?

One skill folder at .agents/skills works in OpenAI Codex, Cursor, GitHub Copilot, Gemini CLI and Google Antigravity, which all read project skills from there.

Is an MCP server an agent?

No. An MCP (Model Context Protocol) server is a program that offers tools, data and prompt templates to an AI application. The agent decides when to call it; the server itself does not plan or decide.

When should you use a hook instead of an instruction?

A hook is the right choice when something must happen every time, such as running a formatter or blocking an edit. An instruction in AGENTS.md, CLAUDE.md or a skill is a request the agent can miss; a hook runs on its event.

Is a hook the same as a CI check?

No. A hook runs inside the coding agent’s session when its event happens, such as after an edit. A CI check runs on every pull request, whoever or whatever opened it, so it still catches changes made outside the agent.

Part 4 of the series is about verifying AI-generated code. More on AI coding is in the AI category.