MCP vs skills vs tools: picking the right Claude extension

I have three extension points available every time I want to give Claude Code a new capability. Tools, skills, and MCP servers. They overlap enough in what they can do that the naming is not decisive. You can technically wrap almost anything in almost any of them.

This is the decision log I use to pick. Six criteria, one clear winner per task most of the time, and a clean fallback when the criteria split.

The fork

I have a capability I want to add. Say, "let Claude generate a branded PDF from a markdown file." Three options.

• A tool call. Write a bash script, wrap it in a Bash invocation with explicit arguments. Runs once per call, no memory, no session state.
• A skill. Package the script plus instructions in ~/.claude/skills/branded-pdf/. Auto-activates on the right keywords, persists across the session.
• An MCP server. Stand up a separate process that exposes generate_pdf as an MCP tool. Available to any MCP-compatible client.

All three will work. One of them is right. The others add overhead without matching payoff.

Option A: tool call

Lifetime: one call, one result, no memory.

What it gives you: the simplest thing that works. No setup, no process management, no distribution problem. You invoke it explicitly each time.

What it costs you: nothing of the model's intelligence is captured. Every call looks like the first call. Context has to be re-specified. If the tool needs three args and you use it ten times, you specify three args ten times.

Pick this when: the capability is used rarely (a few times total, not a few times a day), or when the capability is one call with flat inputs and flat outputs. Example: "run this specific bash one-liner." Tool call.

Option B: skill

Lifetime: the session. Auto-activates on matching content. Persists across multiple calls.

What it gives you: packaged pattern. The model picks it up when the user's message matches the skill's description. Reference files, helper scripts, and example libraries travel with the skill. Session-scoped memory of the pattern (through the conversation).

What it costs you: session-scoped. A skill cannot own a long-running process. It cannot share state across two users or two machines. Auth lives in environment variables on the machine where Claude Code is running.

Pick this when: the capability is a recurring task for one user on one machine. Example: "generate a PR description from a diff." Skill.

The first-Claude-skill walkthrough covers the five-file template I use.

Option C: MCP server

Lifetime: the process. Runs independently of the client. Can be local (stdio) or remote (Streamable HTTP).

What it gives you: a stable protocol. Multiple clients can connect to the same server. State can persist across sessions. Authentication can be centralized. Heavy resources (a browser, a database connection pool, a cache) can be shared.

What it costs you: setup complexity. You now have a process to manage. Authentication, version upgrades, deployment. You pay a protocol tax on every call (serialization, transport, auth).

Pick this when: the capability is shared across multiple clients or needs state that outlives a session. Example: "let the team's agents all query our Supabase project with audit logging." MCP server.

The MCP server architecture post covers the transports and patterns.

The six criteria I use to pick

Each time I add a capability, I run it through six questions.

1. Lifetime

How long does the capability need to remember anything?

• Per call: tool.
• Per session: skill.
• Per process (long-running): MCP.

2. State

Does the capability need to hold state between calls?

• No state: tool or skill.
• Session-scoped state (the conversation is enough): skill.
• Process-scoped state (a browser, a connection): MCP.

3. Sharing

How many clients need to use this capability?

• One client: skill or tool.
• Multiple clients, same machine: still usually a skill (each client loads it independently).
• Multiple clients across machines or users: MCP.

4. Setup cost

How much work is it to build and maintain?

• Tools: low. A bash script wrapped in a call.
• Skills: low. Five files, maybe under 100 lines of markdown.
• MCP: medium to high. A process, a schema, deployment, auth.

5. Auth

Where do credentials live?

• Tool: inline in the command.
• Skill: environment variables on the user's machine.
• MCP: centralized on the server, issued to clients via tokens.

6. Best fit

What is this capability fundamentally?

• A single call: tool.
• A recurring task pattern: skill.
• A shared protocol or service: MCP.

Option C+: the combination

Nothing stops you from combining. A skill can call an MCP server. A tool call can invoke a script that itself connects to an MCP server. The three extension points compose cleanly.

What I do in practice: for common team tools (Supabase, Playwright, GitHub), I use the off-the-shelf MCP server. For my personal workflow patterns (PR notes, audit scans, scaffolds), I write skills. For one-off scripts, I just make the bash call directly without formalizing it.

This layering is why the question "skill or MCP" is sometimes the wrong question. The right question is often "which layer is this capability?" A Supabase query pattern is both. The MCP gives you the query execution. The skill gives you the recurring pattern of "query the orders table and summarize revenue by day."

What I chose and why

Default to skill. Skills are the cheapest thing that captures a recurring pattern. They are fast to write, fast to throw away, and they compound.

Reach for MCP when:

• The capability is genuinely shared across clients or users.
• The capability needs process-scoped state (a warm browser, a connection pool).
• Centralized auth matters (keys should not live on every machine).

Reach for a plain tool call when:

• The capability is one-off, not worth packaging.
• The capability is a single shell command with explicit arguments every time.

What I would revisit

Two calls I have gone back and forth on.

The skill-to-MCP promotion moment. Sometimes a skill I wrote for myself gets used by one more person, then two more. At some point it wants to become an MCP server so it can centralize auth and logging. I have not found a clean signal for "it is time." Usually I notice because someone complains about setup friction.

The MCP-to-skill demotion moment. I have written MCP servers that, in retrospect, should have been skills. A local-only server with one client is almost always a skill wearing a MCP costume. The rewrite is usually not worth doing unless I am touching the code for another reason.

For operators who want the composed pattern (skills + MCP + tools all at once), the Claude Code skills pack ships with a set of skills that call the common MCP servers, showing the composition in practice. The agent engineering handbook indexes the broader decision set.

FAQ