MCP servers vs agent skills: which one you actually need
One gives a model new hands. The other changes how it decides. Confusing them is the most expensive mistake in this space, and it shows up as a context bill nobody budgeted for.
The question arrives in a hundred forms and it is always the same question: should this be a tool or a prompt? MCP answers the first half, agent skills answer the second, and people get it wrong because both are sold as "extending your agent".
A server changes what the model can touch. A skill changes what it does with what it already has.
The distinction, drawn
- An MCP server is a process with tools. The model calls one, something happens outside the conversation, a result comes back. It holds credentials, it can fail, it costs a round trip, and it can be revoked.
- An agent skill is instructions — a procedure, a house style, a checklist, a set of refusals — that the model loads into the session when it matches. It holds no credentials, calls nothing, and cannot fail the way a network call fails. It can be wrong, and being wrong is quieter.
The cost models are mirror images
A server costs a call: latency while it runs, nothing when it does not. A skill costs context: it occupies tokens from the moment it matches, whether or not the model ends up using a word of it.
The uncomfortable part is that none of that is visible while it is happening. There is no error, no warning and no line item — only a session that had less room to think in than the one before it.
Side by side, the two of them differ on every axis that matters operationally:
| MCP server | Agent skill | |
|---|---|---|
| Cost when used | One round trip | Tokens, already spent |
| Cost when not used | Nothing | The same tokens |
| Holds credentials | Often | Never |
| Fails by | Erroring, timing out, being refused | Being confidently wrong |
| Revoked by | Uninstalling or revoking the grant | Removing it from the session |
| Blast radius | Whatever the tools reach | Whatever the model does next |
So the failure modes invert. A badly chosen server sat there and did nothing — irritating, and free. A badly chosen skill loads on every session that mentions a keyword and takes a slice of the window forever, silently, on work it has no business shaping.
They are not alternatives
The pattern that works is boring: the server provides the capability, the skill provides the judgement about when and how to use it.
A migration server can run any query. The skill is what tells the model to take a backup first, run it against a copy, and refuse on a Friday afternoon. Neither half is much use alone — the server is a loaded weapon and the skill is a lecture.
It is also worth remembering that a skill with no credentials is not the same as a skill with no consequences. Plenty of them instruct a model to act rather than only to read, and the acting is done with whatever tools happen to be in the session.
The rule
- If the model needs to reach something it cannot reach — an API, a database, a file system, a browser — you need a server. No quantity of instructions produces a network call.
- If the model can already do it and does it badly, inconsistently, or not in your house style — you need a skill. A server here is an expensive way to write a prompt.
- If you are writing a server whose tools return text the model then has to be told how to interpret, you are writing both — and it will be cleaner, cheaper and easier to revoke as two things.
A practical warning about skill weight
Skills are priced in attention, and attention is the resource you have least of. A heavy skill is a substantial fraction of a working session before the model has read a line of your code. Load it deliberately, scope its trigger tightly, and treat "it might be useful" as a reason to leave it out.
The failure is silent and cumulative: five plausible skills, each justified on its own, and a context window a third gone before work starts. Nothing errors. The model simply gets worse at long tasks and nobody connects the two — which is why this is the one place we would advise being stingy on principle rather than on evidence.