The question gets asked as if one replaces the other, and it doesn’t. A skill and an MCP server only look adjacent because they both arrive as “things you add to your agent.” One is a document; the other is a network protocol. Confusing them produces two expensive mistakes: standing up an MCP server to wrap a command-line tool the agent could already run, and writing an ever more elaborate skill describing an API the agent has no credentials to reach.
The load-bearing distinction is instruction versus connection. A skill is knowledge about how to do something — a folder with a SKILL.md in it, loaded into the model’s context when the task matches. MCP is a protocol that gives a model access to a system it otherwise cannot touch. A skill changes what the model knows; MCP changes what the model can reach.
We maintain a library of open-source agent skills and also get paid to build private MCP servers against other people’s systems, so to be explicit: there are plenty of jobs where the honest answer is “you need MCP, and a skill won’t help.” Those are marked below. This piece assumes you roughly know what a SKILL.md is; if not, start with what an AI agent skill is.
What is MCP actually for?
The Model Context Protocol is an open standard for connecting AI applications to external systems. It is a wire protocol — JSON-RPC 2.0 messages between an MCP host (the AI application), an MCP client (one per connection, created by the host), and an MCP server (a program that exposes some system).
The protocol defines three things a server can expose:
- Tools — executable functions the model can invoke: run a query, file a ticket, send a message.
- Resources — data the client can read into context: a file, a schema, a record.
- Prompts — reusable templates the host can surface to the user. In Claude Code these appear as
/mcp__servername__promptname.
It also defines what a client can offer back: as of protocol revision 2026-07-28, elicitation — a server asking the user for information or a confirmation — is the live client primitive, with sampling and logging deprecated. Two transports are specified, stdio for a local process and Streamable HTTP for a remote one. Authentication lives in the HTTP transport, which supports standard HTTP auth with OAuth recommended for obtaining tokens.
The most useful sentence in the whole MCP documentation is this one, from the architecture overview: “MCP focuses solely on the protocol for context exchange — it does not dictate how AI applications use LLMs or manage the provided context.”
Read that as a boundary marker. MCP is deliberately, correctly silent on how the model should behave. It hands your agent a query tool with a JSON Schema and a one-paragraph description. It will not tell the agent which of your forty tables matter, that orders.status has three legacy values nobody documented, that a full scan on events will time out, or that a refund over a certain size should stop and ask a human. That is the gap a skill fills.
MCP gets the agent into the room. It has nothing to say about what the agent should do once it is standing there.
What does a skill do that MCP doesn’t?
A skill is a folder containing a SKILL.md file: frontmatter with a name and a description, then markdown instructions, plus any scripts or references you bundle alongside. The format was developed at Anthropic, released as an open standard, and is now implemented across a long list of agents under the umbrella of agentskills.io. We cover it in SKILL.md explained and the agent skills standard.
What matters here is the loading model. Agents load skills through progressive disclosure: at startup only each skill’s name and description enter context; the body loads when the task matches; bundled files and scripts load only when the instructions reach for them. Anthropic’s documentation puts the resting cost at roughly 100 tokens per skill and budgets the body at under 5,000 tokens — which is why you can have dozens installed and pay for almost none of them until one becomes relevant.
So a skill is the natural home for procedure and judgement: conventions, sequences, the thing your senior engineer knows that was never written down. None of it is a capability; all of it is knowledge.
Skills vs MCP: the capability table
| Agent skill | MCP server | |
|---|---|---|
| What it is | A folder of instructions (plus optional scripts and references) | A running program speaking a JSON-RPC protocol |
| What it adds | Knowledge, procedure, judgement | Access: tools, resources, prompts |
| Where it lives | In a repo or a config directory, as files | A local process or a remote HTTP endpoint |
| Loaded when | Description at startup; body when the task matches | Client-dependent; increasingly deferred until needed |
| Handles authentication | No — it can only use credentials the agent already has | Yes — that is a core job of the HTTP transport |
| Returns live data | Only if the agent can fetch it some other way | Yes, that is the point |
| Enforceable | No. It is context; the model can ignore it | Partly. The host can gate, log and deny individual tool calls |
| Operational burden | A file to review in a pull request | A service to deploy, authenticate, version and keep up |
| Works offline | Yes | Only for local stdio servers |
| Portable | Yes — the same folder works across agentskills.io-compatible agents | Yes — the same server works across MCP-compatible hosts |
| Best at | Telling the agent how | Telling the agent what it can touch |
Note that portability is not a differentiator; both are open formats with broad adoption. What differs is what you are portable with: a skill travels as text you can read in a diff, an MCP server travels as a deployment.
When is a skill enough — and an MCP server pure overhead?
One question resolves most of these arguments: does the agent already have a path to this system?
If it does, an MCP server frequently adds a service to operate without adding any new capability. The clearest case is wrapping a CLI. Your coding agent can run bash, and gh, aws, kubectl, psql and the rest are already installed, already authenticated on your machine, already documented. Putting a server in front of them buys schema validation and a tidier tool list; it costs a process, a config entry, a dependency to patch, and a permanent translation layer between the model and a tool whose real documentation it can read. What the agent is missing there is not access — it is which commands, in what order, with which flags, and what to do with the output. That is a skill, and a much smaller thing to build.
The same applies to anything already in the working tree. A skill saying “the canonical schema is at db/schema.sql; read it before writing a query; never hand-write a migration, run npm run db:generate” beats a server that re-serves the same file over JSON-RPC.
Two more cases where a skill is the right shape:
- The knowledge is stable and the access is trivial. Coding conventions, review checklists, incident runbooks. Nothing to connect to.
- You want determinism. Bundle a script in the skill folder. The agent runs it and only the output enters context — the source never does. Usually cheaper and more reliable than having the model regenerate equivalent code each time.
There is a governance argument too: a skill is markdown in your repository, so it goes through code review and shows up in git blame. An MCP server is infrastructure, and infrastructure accrues owners, secrets and on-call.
When do you genuinely need MCP?
Often. This is the part skill vendors tend to skip, so let’s be specific about where a skill cannot help you at all.
Live data behind authentication. Jira issues, Sentry events, Salesforce records, a production Postgres replica, a Notion workspace. If the agent has no credentialed route to the system, no amount of instruction manufactures one. MCP exists precisely for this and is very good at it.
Writes you want validated and approvable. A tool call has a name, a JSON Schema, and a discrete invocation the host can intercept — so it can be gated behind an approval prompt, logged, rate-limited, or denied by policy. A skill gets none of that: it is context, and context shapes behaviour rather than enforcing it. When the operation is “issue a refund,” you want the enforcement surface, and MCP is where it lives.
Authentication you don’t want the model near. The Streamable HTTP transport handles bearer tokens, API keys, custom headers and OAuth at the transport layer, so the credential never has to appear in a prompt, a skill body or the transcript. Any design where a skill tells the model to read a secret and paste it somewhere is worse on every axis.
Capabilities that change underneath you. MCP servers can advertise that their tool list changed and notify subscribed clients, so what an agent can do may shift at runtime as permissions change or a feature flips on. A static markdown file cannot express that.
One integration, many agents. If four agents across your company need the same internal system, a single MCP server is the honest architecture. Build once, integrate everywhere is the real promise of the protocol, and it holds up.
Sandboxes without a network. Under-appreciated, and documented: skills running on the Claude API execute in a sandboxed container with no network access and no runtime package installation. A skill that “just shells out to curl” is fine in Claude Code — where skills have the same network access as any other program on your machine — and impossible through the API.
If the choice is between building an MCP server and not solving the problem, build the server.
Can they work together?
Yes, and this is the configuration that actually performs in production: an MCP server that provides the capability, and a skill that provides the judgement about how to use it.
The MCP server for your data warehouse exposes run_query. The skill next to it says: these six tables matter and here is what each column means; always filter by tenant_id; never SELECT * on the events table; if the result exceeds ten thousand rows, aggregate in SQL rather than pulling it into context; for revenue questions the source of truth is the finance mart, not raw events. None of that fits in a tool description, and none of it belongs in one.
The two layers are visibly converging. Claude Code’s MCP documentation tells server authors that the server-instructions field helps Claude understand when to search for their tools, “similar to how skills work.” Meanwhile a Claude Code skill can pre-approve specific tools for the turn that invokes it, and a subagent definition can name the MCP servers it may use. The mechanisms are designed to nest.
A useful frame, borrowed from Clean Architecture: the MCP server is an adapter at the edge, and the skill is the use case that knows what to do with it. Keeping the vendor at the boundary and the judgement in your own layer is the same instinct that stops a database dictating your business logic. It also implies the operational point people skip — an MCP server is an integration point, so it fails like one, and a server that hangs is worse than one that errors: it burns the turn and produces nothing.
Use the release-it skill to design the failure handling for the MCP servers my agent depends on — timeouts on every outbound tool call, a circuit breaker on the third-party one, and a fallback that degrades the session gracefully instead of hanging when a server stops responding
Release It!What does each one cost you in context?
Context is the scarce resource, so the accounting matters.
Skills cost their name and description at rest, for every installed skill, every session — roughly 100 tokens each, per Anthropic’s documentation. The body arrives only when the skill is triggered, but note that in Claude Code a loaded skill stays in the conversation for the rest of the session, with auto-compaction re-attaching recent invocations within a bounded budget. Near-zero until used, then persistent. Write short bodies.
MCP used to be much worse, because every connected server’s full tool definitions loaded upfront and a few chatty servers could eat a serious slice of the window before you typed anything. That has changed. Claude Code now defers MCP tool definitions by default: only tool names and server instructions load at session start, and the model searches for the definitions it needs. Descriptions and server instructions are truncated at 2 KB each.
Two caveats, because this is the most version-dependent thing in the article. Deferral is a client behaviour, not a protocol guarantee — the MCP documentation describes progressive tool discovery as a best practice for clients federating many servers, so other hosts may still load everything eagerly. And Claude Code’s own defaults and thresholds have moved more than once; check the current docs rather than any number from a blog post, this one included.
The guidance survives the churn: skills scale cheaply in number, MCP servers scale cheaply only if your client defers their schemas. Connect the servers you need, not the ones you might.
So which one do you actually need?
Work down this list and stop at the first line that matches.
- The agent has no credentialed route to the system. You need MCP. Nothing else will do.
- The operation writes to something you’d want a human to approve, or a log of. MCP, so the host has a discrete call to gate.
- Several different agents need the same integration. MCP, once, rather than four half-baked wrappers.
- The agent can already reach it (a CLI, the repo, a key in the environment) but keeps doing it wrong. A skill. You have a knowledge problem, not an access problem.
- You already have the MCP server and the results are mediocre. A skill on top of it. This is the most common under-diagnosed case: the connection works and the judgement is missing.
- The rule must hold no matter what the model decides. Neither. Use your client’s enforcement layer — permissions, deny rules, hooks. A skill is context and can be ignored; a tool call can at least be blocked.
Most teams we work with land on 4 or 5, which is unsurprising: MCP has had far more attention than the instruction layer, so the connections are usually already there and the guidance usually isn’t.
Frequently asked questions
Is MCP being replaced by Agent Skills?
No. They operate at different layers and the tooling is converging on using both together. MCP is a transport-and-capability protocol; skills are an instruction format. Anthropic ships and documents both, Claude Code supports both at once, and the MCP docs point server authors at skill-style guidance for their server instructions. The “skills killed MCP” framing comes from a real observation — many early MCP servers were thin CLI wrappers a skill would have handled better — but generalising that into a replacement is wrong.
Can a skill call an MCP tool?
Yes, and it is a good pattern. A skill’s instructions can name which MCP tool to use for a step, in what order, and what to do with the result. In Claude Code a skill can also pre-approve specific tools so the agent doesn’t stop for permission mid-turn, and a subagent definition can restrict which MCP servers are visible to it at all. The skill supplies the procedure; the server supplies the capability it calls.
Does an MCP server bloat my context window?
Less than it used to, and it depends entirely on your client. The historical problem was that every connected server’s full tool schemas loaded at session start. Claude Code now defers MCP tool definitions by default, loading only tool names and server instructions upfront; other hosts may still load everything eagerly. The general advice is unchanged: connect servers you actually use, keep tool descriptions tight, and audit what is loaded if a session feels heavy from the first turn.
When is writing an MCP server a mistake?
When it wraps something the agent could already do. If your server’s tools shell out to a CLI that is installed and authenticated on the machine the agent runs on, you have built a translation layer rather than an integration — a process, a config entry and a schema surface to maintain, in exchange for capability the agent already had. Document the CLI in a skill instead. The exception is a sandboxed environment with no network or no shell, where the wrapper genuinely is the only route.
Do skills work outside Claude?
Yes — the SKILL.md format is an open standard, and agentskills.io catalogues the agents implementing it. MCP has comparably broad client support. Neither locks you to a vendor, but loading behaviour and context accounting differ between implementations, so check your own agent’s docs rather than assuming Claude Code’s behaviour is universal.
Which should I build first?
Whichever removes the current bottleneck. If the agent produces confidently wrong work because it doesn’t know your conventions, build the skill: an afternoon, reviewable, reversible. If it can’t see the system at all, build the MCP server, because no instruction fixes a missing connection. Standing up a new internal agent, the honest sequence is usually to connect the one or two systems it genuinely cannot live without, then spend the rest of your effort on the instruction layer — that is where the quality gap almost always turns out to be.
Where to go next
If the answer is a skill, how to write an agent skill covers the format and the failure modes, and installing skills in Claude Code covers getting one running. If you now need to work out where instructions should live across skills, subagents, slash commands and CLAUDE.md, that is the next comparison.
Our own library packages canonical engineering and business books as agent skills — free, MIT-licensed, one command:
npx skills add wondelai/skills --all --globalAnd if the answer turned out to be “the MCP server and the skill layer on top of it, in production, against systems we can’t hand to a stranger” — that is the work we do. Talk to us.