# Claude Skill or MCP server: which one your team actually needs

**Author:** John Morabito (Founder, /winston)
**Published:** September 20, 2026
**Reading time:** 11 minutes
**Canonical:** https://www.winstondigitalmarketing.com/playbooks/claude-skill-vs-mcp-server/

Two teams asked me the same question in the same week. One wanted Claude to write product descriptions that actually sound like their brand guide instead of like a model doing its best. The other wanted Claude to tell them which campaigns burned budget last month. Both asked whether they should build a Skill or an MCP server, and the right answer was different for each, for a reason that has nothing to do with either feature list.

A Claude Skill is packaged know-how. A folder holding a SKILL.md procedure plus whatever scripts and reference files the job needs, which Claude loads when a task matches the description you wrote for it. It teaches Claude how your team does something.

An MCP server is a connection. A small program that sits in front of a live system, declares the tools it offers, and answers when the model calls one. It gives Claude reach into something it could not previously touch.

The question that decides it is what is actually missing. If the missing thing is knowledge, how we do this, you want a Skill. If the missing thing is access, what the model can reach, you want a server. Teams build the wrong one constantly, and it is almost always because they never said out loud which of those two was the blocker.

## What a Skill actually is

A Skill is a directory. The required piece is SKILL.md, which carries a description telling Claude when this Skill applies and the procedure itself. Alongside it go scripts for the steps that have to come out identical every run, and reference files the model reads when the procedure calls for them. Claude reads the description, decides the task matches, loads the folder, and follows it.

What a Skill changes is how the job gets done. Which steps run and in what order, what the output looks like, which rules are not negotiable, what gets checked before anything is handed over. It is the thing you would have written down for a new hire, except a model can follow it at three in the morning without asking you a clarifying question.

The ceiling is the part people skip. A Skill cannot fetch anything. It does not widen what Claude can see by a single row. If your procedure opens with "pull last month's spend from the ads account," the Skill can specify exactly how that data gets handled once it exists, and nothing in the folder will make it appear. Somebody exports a CSV and pastes it, or the Skill stalls at step one. The full build guide, including which workflows are worth packaging first and how to split instructions from scripts from references, is in [Claude Skills for SEO teams](https://www.winstondigitalmarketing.com/playbooks/claude-skills-for-seo-teams/).

## What an MCP server actually is

MCP is an open standard for connecting a model to an outside system. A server is a program that speaks it. It sits in front of a CRM, an ad platform, a database, a ticketing system, or your own internal service, and it publishes a list of tools: read this, search that, list the other thing. Claude sees the list, calls a tool when the work needs it, and gets structured data back instead of a guess.

What a server changes is what Claude can touch. That is a real jump in capability, because most of the reason a model gives you a vague answer about your own business is that it has never seen your business. A connection fixes that in a way no amount of instruction can. The practical introduction, including which systems are worth connecting first and what a build involves, is in [MCP servers for marketing teams](https://www.winstondigitalmarketing.com/playbooks/mcp-servers-for-marketing-teams/).

The ceiling here runs the opposite direction. A server supplies capability and nothing else. It hands Claude a set of buttons and the data behind them, and it has no opinion at all about which button to press, in what order, toward what deliverable, or what a good result looks like when the work comes back. Connecting the ad account does not make anyone better at reading ad accounts. It just means the numbers are now in the room.

## Knowledge or access: the question that settles it

Write down the sentence you wish you could type to Claude and have it just work. Then read it back and finish this sentence: it does not work today because...

There are really only two endings. Either it does not know how we do this, which is knowledge, or it cannot get to the thing, which is access. Knowledge builds a Skill. Access builds a server.

When that is ambiguous, run the paste test. Today, do you make the workflow happen by pasting something in, an export, a doc, a screenshot, and is the output fine once you do? Then the blocker is access, and everything you are about to write in a Skill is an elaborate way of avoiding a connection. Or do you paste in everything it could possibly need and the answer still comes back in the wrong shape, missing the rules, generic where it should be specific? Then the blocker is knowledge, and a server will hand that same wrong answer to more data.

The test has a third outcome that catches good teams. Sometimes the paste works, the output is fine, and the job still takes an hour, because the hour is the pasting. That is an access problem wearing a productivity costume, and it is the cleanest case for a server there is.

## The two builds that go wrong

The failure modes are mirror images, and each one is obvious from the outside and invisible from the inside.

**The Skill that needed access.** A team writes a genuinely good reporting Skill. The structure is right, the thresholds are right, the tone is right. Step one is "retrieve the performance data," and a person does that by hand on the first Monday of every month. The Skill works, in the sense that it produces the report, and the work never actually got faster, because the part that hurt was never the writing. The tell is a procedure with a manual step at the top and a Skill that only runs when somebody remembers to feed it.

**The server that needed a procedure.** A team connects the ad account. The demo is great. Everyone asks it a question, gets a real answer, and then two weeks later nothing about the monthly work has changed. The reason is that "look at my account and tell me what to fix" is a question, not a process, and the answer arrives differently shaped every time, so nobody can build on it. The tell is a connection that works perfectly and a workflow that is exactly where it was.

Both start from the same mistake, which is treating the thing you build as the goal instead of naming the gap first. Nobody wants a Skill. They want the report to stop eating a Monday.

| Dimension | Claude Skill | MCP server |
|---|---|---|
| What it supplies | Knowledge: how the job is done here | Access: what the model can read and act on |
| What it is | A folder of instructions, scripts, references | A running program that exposes tools |
| The complaint it fixes | It does not do this our way | It cannot see our data |
| Where it lives | A repository, copied anywhere | A process somebody hosts and keeps up |
| Who owns it | Whoever owns the procedure | Whoever owns the system and its credentials |
| Needs credentials | No | Yes |
| How it fails | Quietly goes stale against a changed process | Goes down, expires a token, or meets an API change |
| Reviewing it | Read the file | Read the file, then audit scopes, writes, and logs |
| Cost to try | An afternoon of writing | Engineering time plus somewhere to run it |
| Cost when wrong | Output you can see and reject | Actions taken in a live system |

## The common shape is both

The versus framing is a search habit. On anything we run for more than a month, the useful build is a Skill that calls an MCP server. The server supplies the reach. The Skill supplies the judgment. Neither half is interesting alone.

Monthly reporting is the clearest example. The server exposes read access to the analytics and search data, so the numbers arrive without a human in the middle. The Skill decides which numbers matter, how to segment them, what size of change is worth a sentence, what the document looks like, which claims a person has to sign off on before it goes anywhere. Take the server away and the Skill needs a volunteer with a CSV. Take the Skill away and you have a very fast way to produce a different report every month.

The build order matters more than people expect, and it runs opposite to instinct. Write the Skill first, against pasted data. It costs an afternoon, and it forces the question of whether the procedure exists at all, which is the thing most teams find out too late. It also tells you exactly which fields the server needs to expose, usually a much shorter list than the API offers. Teams that connect first tend to publish every tool the platform has, then discover the work only ever touches four of them, and now there are twenty more doors than the job requires.

## What each one costs to keep

A Skill is a folder in git. It has no uptime, no credentials, no dependencies, and no way to wake you up. The only way it fails is by describing a process that has since changed, which is a real failure and a slow, visible one. You fix it by editing a file, and the diff shows what changed and when.

A server is software you now run. Something has to host it. It holds credentials that expire, it has dependencies that need updating, and the system on the other side will change its API without consulting you. When it breaks, it breaks for everyone at once, and the person who can fix it is usually not the person who wrote the marketing procedure. Some servers you do not host at all, because a vendor publishes one for their own product, and that moves the uptime problem off your desk without changing the credential question or the access question at all.

None of that is an argument against servers. It is an argument for counting them. Each one is a small piece of internal infrastructure with a name on it, and a team that would not agree to run six little internal apps should notice when it has agreed to exactly that, one connection at a time.

## The security surface a server opens

This is the part of the comparison that gets skipped in the excitement, and it is the one I would lose sleep over.

Reviewing a Skill means reading a file. It runs where Claude already runs, with whatever the session already had. If it is wrong, you get bad output, and bad output announces itself.

A server is a door into a live system, so the questions are the ones you would ask before handing a new contractor a login.

- **What can it read?** Plenty of integrations default to the entire account because that is the easy scope to request. The work almost never needs the entire account.
- **What can it write?** Read-only versus can-change-things is the single most consequential setting on the whole build. Start read-only. Add write tools one at a time, deliberately, each with a reason.
- **Whose credentials?** A server running on one admin's account makes every action in the audit log look like that person did it, which is the opposite of what you want the first time something goes sideways.
- **What leaves the system?** Whatever a tool returns becomes part of a conversation. Customer records and revenue detail are easy to pull in without anyone deciding that they should be.
- **Who can invoke it, and is anyone watching?** If you cannot answer who called which tool last Tuesday, you have given out a login with no logging.

Prompt injection is where the two options genuinely diverge. Once a model has tools, any untrusted text it reads, a web page, a support ticket, a review, an inbound email, can attempt to instruct it. A Skill that reads a hostile page writes a bad paragraph and you delete it. A server with write access that reads the same page can take a real action in a real system. That gap is why every server should start read-only.

## Where to start this week

1. Take the workflow that annoys you most and write it as steps that end in a specific artifact. If you cannot get it into a list, that is the finding, and neither build will save you.
2. Mark every step that is slow because Claude cannot reach something. That column is access.
3. Mark every step that comes back wrong even when you hand it everything. That column is knowledge.
4. Build the knowledge column first, as one Skill, running on pasted data. An afternoon buys you a working procedure and an exact specification for what a connection would need to supply.
5. Then connect the one system the access column kept pointing at. One server, read-only, scoped to the fields the Skill actually reads.
6. Delete the paste step. That deletion is the whole return on the project, and it is worth naming so somebody notices it happened.

If your comparison is really happening inside Claude rather than across the stack, the other axis is context versus procedure, and that one is covered in [Claude Projects vs Claude Skills](https://www.winstondigitalmarketing.com/playbooks/claude-projects-vs-claude-skills/). Knowledge and access is the build question. Context and procedure is the packaging question. Most teams need an answer to both, and they are not the same answer.

Working out which half of a workflow is missing knowledge and which half is missing access, then building only the part that is genuinely missing, is what our [custom GPTs and Skills service](https://www.winstondigitalmarketing.com/services/ai-marketing/custom-gpts-and-skills/) does with clients.

## Frequently asked questions

### What is the difference between a Claude Skill and an MCP server?

A Claude Skill is packaged knowledge. It is a folder containing a SKILL.md procedure plus any scripts and reference files the job needs, and Claude loads it when a task matches the description you wrote for it. It changes how a job gets done. An MCP server is access. It is a running program that sits in front of a live system, publishes a list of tools, and answers when the model calls one, so it changes what Claude can reach. The deciding question is which of those two things is missing. If Claude does not know how your team does the work, build a Skill. If Claude cannot get to the data or the system, build a server. A Skill will never widen what the model can see, and a server will never supply judgment about what to do with what it finds.

### Can a Claude Skill pull data from my ad account or CRM?

No. A Skill is instructions, scripts, and reference files, and none of those can reach a system that Claude has no connection to. If a procedure you wrote into a Skill begins with retrieving live data, that step will be done by a person pasting an export, every single time, and the Skill will only run when somebody remembers to do it. That manual step at the top of an otherwise good Skill is the clearest sign that the real blocker was access rather than knowledge. The fix is an MCP server for that one system, scoped to the fields the Skill actually reads, with the Skill left in place to do the part it was always good at.

### Can a Claude Skill use an MCP server?

Yes, and that combination is the shape most production setups end up in. The server supplies reach into the live system and the Skill supplies the procedure that decides what to pull, how to interpret it, what the output looks like, and what a human has to approve. Monthly reporting is the standard example: the server exposes read access to the analytics data, and the Skill decides which changes are worth writing about and what the document should say. Build the Skill first, running against pasted data, because that is what tells you whether the procedure actually exists and exactly which fields the server needs to expose. Connecting first usually produces far more tools than the work will ever call.

### Which is more work to maintain, a Skill or an MCP server?

A server, by a wide margin. A Skill is a folder in version control with no uptime, no credentials, and no dependencies, and its only failure mode is quietly describing a process that has since changed, which you fix by editing a file. A server is software somebody has to run. It holds credentials that expire, dependencies that need updating, and it faces an API on the other side that can change without warning. When it breaks it breaks for everyone at once, and the person who can fix it is rarely the person who wrote the procedure. Some servers are published by a vendor for their own product, which moves the hosting burden but leaves the credential and access questions exactly where they were.

### What security risks does an MCP server add that a Skill does not?

A server is a doorway into a live system, so it raises the questions you would ask before giving a contractor a login. What can it read, given that many integrations default to the whole account. What can it write, which is the most consequential setting on the build. Whose credentials it runs on, because every action will appear in the audit log as that person. What data leaves the system once a tool returns it into a conversation. Who can invoke it, and whether anyone is logging that. Prompt injection is where the gap is widest: once a model has tools, untrusted text it reads can try to instruct it, and a Skill that reads a hostile page produces a bad paragraph while a server with write access can take a real action. Start read-only and add write tools one at a time.