When to use a skill, and when you need an MCP server

These two get compared as alternatives and they are not alternatives. They fix different problems, and knowing which one you have saves a lot of wasted effort.

The short version: a skill changes how an assistant approaches a job. An MCP server changes what it can reach. If your assistant is doing the wrong thing, you want a skill. If it cannot do the thing at all, you want a server.

The test that settles it

Ask one question about your problem: would a very well briefed human with no internet connection be able to do this?

If yes, your gap is instructions, and a skill is the answer. Judgement, ordering, formatting, knowing which traps to avoid, applying your house conventions. All of that travels fine in a markdown file.

If no, your gap is access, and no amount of instruction will close it. Resolving a DNS record, completing a TLS handshake, reading a live HTTP response, querying your database. The assistant needs something that can make the request.

This is worth being strict about, because the failure mode is expensive. A skill wrapped around a capability that does not exist does not fail cleanly. It produces a confident, plausible, invented answer. An assistant told to "check the domain's SPF record" with no way to look anything up will describe an SPF record. It will be well formed and it will not be yours.

Why instructions cannot reach the network

There is a hard architectural reason, not just a practical one. Skills running through the Claude API execute in a sandboxed container with no network access and no runtime package installation. That is documented and deliberate.

So a skill cannot be your path to live data. At best it can describe the method and name the tool. Something else has to be holding the connection.

In Claude Code the picture is less absolute, because the assistant has a shell and could in principle run dig or curl if those exist on the machine and it has permission. But relying on that is fragile: the binaries vary, the output formats vary, permissions get in the way, and you have no rate limiting or guard rails. A server that exposes the check as a named tool is the stable version of the same thing.

What each one is good at

Skills are good at:

• The order to do things in, so step three does not run before step one
• Traps that are not in the model's general knowledge
• Your conventions: naming, output format, what to escalate
• Reference material that loads only when needed
• Deciding when a job is finished

MCP servers are good at:

• Live facts: DNS, TLS, HTTP, mail records, IP reputation
• Anything behind credentials
• Operations with real consequences, where you want one audited path
• Giving the same answer to every caller

Most real setups are a pair

Once you separate them, the natural design is obvious: the server provides the reach, the skill provides the judgement about how to use it.

A worked example. "Why is our mail going to spam" is a job with both halves.

The reach: eight read only network checks from toolhq's MCP server, one command to add.

claude mcp add --transport http toolhq https://toolhq.io/api/mcp

The judgement: the order to check records in, and the traps.

---
name: email-deliverability
description: Diagnose why mail from a domain is rejected or filtered as
  spam. Use when a user reports bounced mail, messages landing in spam,
  or asks about SPF, DKIM, DMARC or MTA-STS.
---

# Email deliverability triage

Look every record up with the toolhq checks. Never state a record's
contents from memory.

1. `mx_lookup`. No MX means no inbound mail, and nothing else matters.
2. SPF via `dns_lookup`. Count the DNS lookups the record causes; over
   ten is a hard failure, and nested `include:` is what pushes it over.
3. DKIM for the selectors the sender actually uses. A missing selector
   looks identical to a broken one, so confirm which are in use first.
4. DMARC last. It depends on the two above, and reading it first leads
   to the wrong conclusion.

Report the cause, the evidence with the record contents, and the fix.

Neither half works alone. Without the server the skill invents records. Without the skill the assistant has eight checks and no idea that DMARC should be read last, which is exactly the mistake that makes people change the wrong record.

A decision table

That last row matters more than it looks. Hashes, timestamp conversions, character counts and JSON validation are things models get wrong in ways that instructions do not fix. Where an exact tool beats an AI model makes that case with examples.

Cost, which usually decides it

Skills are close to free until used. The name and description sit in context permanently at roughly 100 tokens each, and the body loads only when the skill fires. Ten skills cost about a thousand tokens whether or not you use them.

MCP servers are the opposite. Every tool a connected server exposes is described to the model on every request, whether relevant or not. Connect several broad servers and you spend a lot of context describing tools nobody is going to call.

So: be generous with skills, deliberate with servers. If a server exposes sixty tools and you need four, that is worth noticing.

Where to go next

If the gap is reach, what MCP is and why an agent needs real network tools explains the protocol, and debugging DNS, SSL and mail with an AI agent shows it running on a real fault.

If the gap is judgement, how to write your first agent skill builds one line by line, and agent skills by type of work lists what is worth writing.