Skills vs MCPs: different jobs, often confused_
Claude skills are packaged instructions that shape how the model behaves on a task. MCP servers are connections that let the model actually touch the real world — files, databases, APIs. One is the playbook; the other is the toolbox. People mix them up constantly because both ship as "extensions" you install into Claude.
Both feel like "add-ons." That is where the confusion starts.
Open any AI tool's documentation and you will see two parallel concepts: "things you install to make the AI better at a task" and "things you install to give the AI access to a system." For Claude specifically, those are skills and MCP servers respectively. They both show up under "extending Claude," they both live in config files, and they both sound vaguely like plugins. So people treat them as interchangeable. They are not.
The clearest way to keep them straight: a skill is something the model reads. An MCP server is something the model uses. A skill cannot do anything on its own — it is just text that gets injected into the model's context at the right moment. An MCP server cannot think — it just exposes capabilities the model can call.
Most real setups need both, and they often work together. The skill knows when to call the tool. The MCP server provides the tool. Skip the skill and the model has tools it does not know when to use well. Skip the MCP and the model has good instincts but no hands.
Skills vs MCP servers, line by line
| Question | Claude Skill | MCP Server |
|---|---|---|
| What is it, fundamentally? | A markdown file with instructions for the model | A running program exposing tools and data |
| Does it run code? | No — just text loaded into context | Yes — a real process on your machine or server |
| Can it read your files? | No | Yes, if you wire it up (e.g., filesystem server) |
| Can it hit an API? | No | Yes — that is most of what they do |
| Who provides it? | You, your team, Anthropic, community | Anthropic, third parties, your own custom code |
| How does the model find it? | Auto-discovery from skills directory + manual | Declared in client config; always available |
| Cost to add | A markdown file. Minutes. | Install + config. Hours for custom servers. |
| Security blast radius | Limited — text injection only | Real — depends on what the server can touch |
| Best mental model | A playbook the model reads before working | A power tool the model can pick up and use |
The interesting work happens when skills drive MCPs
A useful pattern shows up once you have both: write a skill that knows how to use a specific MCP server well. The skill becomes the model's mental model for the tool — when to call it, which arguments matter, what the response format means, what mistakes to avoid.
Concrete example. You install a Postgres MCP server pointed at your production read replica. Without a skill, Claude will query whatever it feels like — sometimes well, sometimes not. With a skill called "querying the customers db," you tell Claude: the customers table is partitioned by region; always filter by created_at to avoid full scans; the email column is hashed in production, look up the raw email in the customer_pii table only if explicitly asked; here is the safe pattern for paginated reads.
Now the model has both. The MCP gives it the connection. The skill gives it the institutional knowledge of how to use that connection well. That is the difference between an AI that can technically reach your database and an AI you trust to actually run things in production.
The same pattern shows up everywhere. A "writing-prs" skill that calls the GitHub MCP server. A "creating-issues" skill that knows your project's label conventions. A "deploying" skill that wraps a Vercel MCP. Each one is a few paragraphs of instructions plus a reference to the tool that does the work.
Decision guide
Reach for a skill when
- The model already has the capability — it just keeps doing it wrong or inconsistently.
- You have an opinion about how something should be done that you keep repeating in chat.
- Multiple teammates need to get the same result from the same prompt.
- You want to encode a workflow ("when reviewing a PR, always check X, Y, Z first").
Reach for an MCP server when
- The model literally cannot do the thing because it has no connection to the system.
- You are tired of copy-pasting data into the chat.
- You want the same integration available across multiple AI tools.
- The capability needs to be durable — same data source, every session.
Reach for both when
- The system you are connecting to has nuance — special tables, custom auth, project conventions.
- Multiple people on your team will use the same setup and you need consistency.
- You are setting up production-grade AI workflows, not just personal experiments.
The trap is treating one as a substitute for the other. Adding more skills will not give the model new capabilities. Adding more MCPs will not give the model better judgment. Each does its own job.
Common questions
Can a skill do the job of an MCP server?
+
No. A skill cannot make a network call, read a file on its own, or query a database. A skill is text that gets loaded into the model's context — it can include instructions to use a tool, but the tool itself has to exist somewhere else. If you want the model to actually do something in the real world, that real-world capability comes from an MCP server, a built-in tool in the harness, or a function the developer wired up. Skills tell the model how. MCPs give the model the ability.
Can an MCP server do the job of a skill?
+
Also no. An MCP server gives the model new capabilities — but it does not change how the model thinks about the task. Without good instructions, the model might have access to your Postgres database via MCP and still write terrible SQL or query the wrong table. A skill tells the model 'when you query this database, always filter by tenant_id; the public schema is read-only; here is the safe pattern for paginated results.' Capability + instruction. You usually need both.
If I had to pick one, which gives me more?
+
MCP servers, almost always. A model with no skills but real tools can still do useful work — clumsily, but really. A model with great skills but no tools can only output text. Capability beats instruction when you can only have one. That said, the better answer is to stop framing it as either-or. Setting up one MCP server and writing one skill that uses it well is the standard pattern, and neither half takes long.
Where do skills and MCPs live on my machine?
+
Skills for Claude Code live in ~/.claude/skills/<name>/ (global, available everywhere) or .claude/skills/<name>/ inside a project (scoped to that repo). Each skill is a folder with a SKILL.md file at minimum. MCP server configurations live in your client's config — for Claude Desktop, that is claude_desktop_config.json; for Claude Code, that is the .mcp.json or settings file. The MCP server itself is a separate process — usually a node or python binary somewhere on disk — that the client launches when it needs it.
Are skills a Claude-only thing or are they standardized like MCP?
+
Skills are currently a Claude/Anthropic concept. They map closely to ideas other tools have — Cursor rules, Cline custom instructions, Cody commands — but the file format and discovery mechanism are not yet a cross-vendor standard the way MCP is. If you write skills for Claude Code today, do not expect them to drop into Cursor unchanged. The general principle (packaged instructions for the model) transfers; the file format does not.
I see people share "skill packs" online. Are those safe to install?
+
Skills are plain text loaded into the model's context — they cannot, by themselves, execute code or read your files. A malicious skill is essentially a prompt injection: instructions that tell the model to do something unhelpful. That is bad, but limited. The risk goes up if a skill instructs the model to use specific MCP tools you also have installed — then the skill's instructions can effectively drive your tools. Treat third-party skills the way you treat third-party scripts: read them before you load them, especially anything that mentions writing files, running commands, or hitting external APIs.
Do I need both for a small one-person setup?
+
Probably yes, even at one person. The first MCP server most people install is the filesystem server, because it removes the constant copy-paste friction of working with Claude on code. The first skill most people write is something like 'how I prefer my code commented' or 'how to structure responses for code review.' Each takes under an hour. Both pay back immediately.
Want both set up properly?
Picking which MCP servers your team needs, writing the skills that make them work consistently, and getting both deployed across every AI tool your team uses — that is the bulk of what a fractional AI engagement actually delivers. Tell the duck what your team uses today and what it is supposed to do tomorrow.