Claude Code Skills vs MCP vs Subagents: Which to Use When

Claude Code Skills vs MCP vs Subagents: Which to Use When

Claude Code skills, MCP and subagents solve different problems. A skill is reusable instruction (how to do something the way your company does it). MCP is the connection to an external system (where the data comes from and where the action happens). A subagent is a task delegated to a worker with its own context and permissions. The choice starts with what is missing: method, access or isolation.

Key takeaways

• If method is missing, use a skill: a procedure written once and loaded only when the task calls for it.
• If data or an action in another system is missing (CRM, ERP, calendar, database), use MCP, with minimal permissions and read-only first.
• If the task is long, noisy or independent and clutters the main conversation, use a subagent.
• The three combine: a subagent can follow a skill and use an MCP tool, each with its own role.
• Start with the simplest option that is cheapest to control. Usually that is a skill, then read-only MCP, and delegation last.

What each one solves, in operations terms

It helps to separate what comes from official documentation, what comes from implementation experience and what is a hypothesis. In this article, the definitions below follow the documentation of the products and the protocol. The recommendations on order and caution come from implementation experience. When something is a hypothesis, we will say so.

A skill is a folder of instructions (and sometimes supporting files or scripts) that the agent loads when the task matches its description. Think of a standard operating procedure: how to build a proposal, how to review a contract, how to write an after-sales reply in the company's tone. It gives access to nothing new. It changes the way the work is done. For the step-by-step creation process, see our article on Claude Code skills.

MCP (Model Context Protocol) is an open standard for connecting AI applications to external systems. In practice, an MCP server exposes tools, data and prompt templates for the agent to use. It is what lets the agent look up an order in the ERP, read a ticket or create a calendar event. The protocol's official introduction is in the MCP documentation at modelcontextprotocol.io. For setup, see local, project and user scopes in Claude Code.

A subagent is a helper agent that receives a task, works in a separate context with its own instructions and tools, and returns a summarized result to the main agent. It brings no new knowledge or new access by itself. It brings separation: of context, of permissions and of responsibility. We cover this in Claude Code subagents.

A short way to remember it:

A skill teaches the how, MCP delivers the access, a subagent divides the work.

A decision tree in four questions

Answer in order. Stop at the first yes that solves the whole problem, and move on only if something is still left over.

• Question 1: does the agent already have the information and tools it needs, but get the way of doing it wrong (format, tone, criteria, order of steps)? Then write a skill.
• Question 2: does the task require reading or changing something that lives outside the conversation (a system, database, spreadsheet, API)? Then you need access, and the path is MCP (or a direct API call, if the flow is fixed and simple).
• Question 3: does the task produce a lot of intermediate material (searches, file reads, drafts) that only matters as a summary, or does it need different permissions from the main conversation? Then delegate to a subagent.
• Question 4: does the result depend on human judgment, sensitive data or an irreversible action? Then, before choosing a tool, define where human approval enters. None of the three replaces that step.

A useful shortcut: turn the name of each option into a question. A skill answers how to do it. MCP answers where to look or where to act. A subagent answers who does this without disturbing everything else.

When a skill is the right answer

Use a skill when the knowledge belongs to the company and repeats. A good sign is catching yourself pasting the same instructions into several conversations. Another sign is two people on the team getting very different results for the same task because each one asks in a different way.

Good candidates:

• A standard for customer replies, with tone, limits on what can be promised and when to hand off to a person.
• A review routine (for code, contracts or proposals) with explicit criteria.
• A fixed format for reports or meeting summaries.
• Rules for filling in a record, such as which fields are mandatory.

What a skill does not do: it does not grant permission and it does not guarantee the step was followed. If the procedure says never to send without approval, that rule also needs to exist as a technical control (denied permission, an approval step), not only as text. This is an operations lesson: instructions reduce errors, but configuration is what enforces limits.

Another point is size. A huge skill that tries to cover everything loses the benefit of loading only what is needed. Anthropic's guidance on context engineering for agents points in this direction: give the agent the smallest set of information that solves the task, at the right moment. Prefer several small skills with clear descriptions of when each applies.

When MCP is the right answer

Use MCP when the agent needs something that is not in the conversation and changes over time: order status, stock balance, a free slot on the calendar, the history of a lead. If the information is stable and fits in a document, a skill or a context file may be enough, and you avoid one more connection to maintain.

Questions to decide whether an MCP server is worth it:

• Does the data change often and need to be current?
• Does the action happen in a system the team already uses, with access control?
• Will several different tasks reuse the same connection?
• Can you start with read-only access?

If the last answer is yes, start there. Read-only first is an implementation rule that reduces risk: you observe how the agent uses the data before allowing any write. We wrote about this in how to build an MCP server for internal systems.

Three precautions that matter more than the choice of technology:

• Minimal permissions: the server's credential should see only what is necessary, at the narrowest scope. The OWASP guidance on authorization is a good reference for the principle.
• Server origin: a third-party MCP server is code running with access to your data. Before installing, follow a routine like auditing an MCP server before installing it.
• Well-designed tools: clear names, objective descriptions and lean responses make the agent err less. Anthropic's article on writing tools for agents covers this in detail.

A data protection reminder: when you connect a system holding customers' personal data, MCP becomes a path through which that data is processed. That belongs in your mapping of purpose, legal basis and who has access, a subject that Brazil's data protection authority (ANPD) oversees under the LGPD.

When a subagent is the right answer

A subagent solves a work organization problem, not a knowledge problem. The most common reasons to use one:

• Isolating noise: a research task that reads many files or pages and returns only a summary, keeping the main conversation clean.
• Separating permissions: a read-only subagent to investigate and another, even more restricted, for sensitive tasks.
• Parallelizing independent tasks: reviewing different modules at the same time.
• Getting a second opinion with different instructions, such as a reviewer who has not seen the author's reasoning.

When not to use one: if the task is short, if each step depends on the previous one and on what the user just said, or if you cannot yet measure whether the result improved. Anthropic's Building effective agents recommends starting with the simplest solution and adding complexity only when there is a demonstrated gain. That applies directly here: every subagent is one more thing to observe, test and limit.

A hypothesis to validate in your own case: delegation tends to help more when the subagent's output is easy to check (a list of findings with references) than when it is an open-ended judgment. Test it with a real workflow before generalizing.

Illustrative scenario: after-sales at a home appliance store

Imagine a home appliance store that serves customers on WhatsApp and wants an internal assistant to support its after-sales team. This scenario is illustrative and unrelated to any real customer.

The problem shows up in three layers, and each one calls for a different option:

• Replies vary from agent to agent and sometimes promise exchanges outside policy. That is missing method: a skill with the exchange policy, the tone and the cases that go to a manager.
• The assistant needs to know whether an order was delivered and what the product warranty is. That is missing access: a read-only MCP server over the order system, with a restricted credential.
• When a long complaint arrives with attachments and the history of several conversations, the assistant has to pull the history without filling its context. That is missing isolation: a read-only subagent that looks up the history and returns a summary with references.

In deployment order, the skill comes first, because it is cheap and already improves consistency. Then MCP comes in, with lookups only. The subagent enters only if the volume of history really gets in the way. At the start, no reply goes to the customer without a person reviewing it. For the messaging layer, the care needed with opt-in and templates is covered in WhatsApp outbound messages.

How to apply it with method: map, limit, pilot, hand over

The method we use in projects follows four moves, and they help you pick the right option without being swayed by novelty.

Map: describe the current process and the starting point. Who does it, with which systems, where it goes wrong, where it waits. Without this, you cannot tell whether the problem is method, access or volume. A guide for this step is mapping business processes before applying AI.

Limit: define which data the agent sees and which actions it can run. Here, MCP permissions and the tools released to each subagent become explicit decisions, not inherited defaults.

Pilot: choose one real workflow, with a log of actions and a success metric agreed before you start. If the skill alone reaches the goal, there is no reason to add MCP or a subagent.

Hand over: deliver the setup to the team running it, with documentation of what each piece does, who maintains it and how to review it. After that, the decision is to expand, adjust or stop.

A final checklist before turning on any of the three:

• Is it clear which problem the option solves: method, access or isolation?
• Does a simpler alternative exist, and was it ruled out for a concrete reason?
• Are permissions minimal and starting at read-only?
• Is there a record of what was consulted and what was done?
• Does a person approve any irreversible action or anything involving sensitive data?
• Does someone on the team own the maintenance of each skill, connection and subagent?

For the protection side, permissions and sandbox in Claude Code complement this checklist, and the OWASP prompt injection prevention guidance covers the risk of injected instructions in content coming from tools.

Frequently asked questions

Do skills and MCP do the same thing? No. A skill delivers instructions and sometimes supporting files on how to carry out a task. MCP delivers access to external systems and data through tools. A skill can guide the agent to use an MCP tool well, but neither replaces the other.

Do I need subagents to start using AI in my company? Usually not. For most first workflows, a well-written instruction (a skill) and, if needed, a read-only lookup (MCP) are enough. Subagents become worth it when the task clutters the context or requires different permissions, and that shows up when you observe the pilot.

Is it safe to connect a third-party MCP server? It depends on the server and how you configure it. It runs with the access you give it, so audit its origin, limit permissions and start read-only. If the system holds personal data, include the connection in your LGPD mapping.

How do I know the choice worked? Compare against the mapped starting point, using the metric agreed at the start of the pilot and the logs of the agent's actions. If an option added complexity without improving that metric, remove it. There is a routine for this in how to measure an AI automation pilot.

Sources

• Model Context Protocol: introdução
• Anthropic: Building effective agents
• Anthropic: Effective context engineering for AI agents
• Anthropic: Writing effective tools for agents