Skills vs MCP: procedural knowledge or live tool access

The question everyone lands on

Usually there's a certain thing you keep doing by hand and would like the agent to do instead, and then there's two offerings on the market: either you can create a skill or run an MCP server. These are both being marketed as extending the agent's capabilities, but really, one of them does it, the other — not so much

A skill is a file, a server is a process

In terms of the differences, what's key is that they're completely different things under the hood. A skill is essentially a directory with a SKILL.md file inside (it's an industry standard established by Anthropic and then opened up). That directory can contain a couple of more things like scripts, reference docs etc but crucially, it contains a markdown file with instructions, which includes metadata like name and description, and that's what the skill is. An MCP server on the other hand is a live process, while the Model Context Protocol is generally client-server, so the host harness spins up a new client for every connected server, with its own connection to it.

There are three primitive types of things an MCP server can expose:

• tools — which are basically functions that AI apps call in order to perform actions

• resources — which are data sources providing context

• prompts — which are templates for structuring conversations with LLM-s

The most important thing is that a skill is knowledge the agent didn't have, while an MCP server is reach the harness didn't have. The former tells you how to do sth, the latter allows you to contact sth. So if you reckon that a competent developer at your terminal could get the job done using what's already installed on it, and the only thing missing is that the agent doesn't know the procedure — that's a skill; if there's nothing that could touch the target — that's a server

What the model actually sees

We could now get into a long discussion about context, but let's just do some math.

When you define a skill at startup, only its name and description are being loaded into the context, which is enough for the agent to understand it's relevant. When it then faces a task it might be relevant for, the entire SKILL.md file gets pulled in; during the task's execution, any additional files included in the skill are being loaded as needed.

Codex has a codex debug prompt-input command that renders the model-visible prompt input as JSON without calling a model at all. Run in a scratch directory with eleven skills, the skills block weighs 6,356 characters — names, descriptions and file paths, no bodies — but if we now list all the SKILL.md files, they actually add up to 122,636 characters. So it's roughly 5% being paid upfront, the rest — on demand. It's also important to note that OpenAI restricts this list to 2% of the context, 8,000 characters.

But when it comes to tools, what's interesting is that it works the other way round: the client asks every connected server for its tools and merges them all into a single registry the LLM can access. So every tool comes with its name, title, description, and an inputSchema — the complete JSON Schema describing the shape of its inputs — all visible to the model before the user types anything in; which is why Anthropic writes:

In cases where agents are connected to thousands of tools, they'll need to process hundreds of thousands of tokens before reading a request.

And their own way out of it is to stop calling the tools directly — generate the code that calls them instead, so the agent only pulls in what it needs. In their worked example that's the difference between 150,000 and 2,000 tokens. But there are a few caveats here:

• it's an extreme scenario — using thousands of tools is not something you do with three modest servers

• it's about the client, not the protocol; the spec leaves room for the client to implement federating multiple servers to discover tools progressively, rather than pulling them all in upfront, so if yours doesn't, that's a harness problem

Another thing that we often see being omitted by advocates of MCP is that skills also rent their space. In Claude Code docs it's clearly stated that once loaded, the skill's content remains in the context turn after turn — so every line of it is a recurring token cost. A 400-lines-long skill pulled in at turn two will still be there on turn forty

The three questions that settle it

So whenever you consider an MCP server, ask yourself three questions:

1. Does this require a connection that can't be established from the machine's shell? — like credentials the agent shouldn't have access to, or an unreachable network, or a SaaS product with no CLI client; in such case it's a server and there's no skill that could replace it

2. Does it need to return a handle so you can revisit it later? — like long-running jobs, or a list of capabilities that change during the session; the protocol covers both scenarios, via Tasks extension (which introduces a durable handle for the LLM to return so the client can poll for the result later), and notifications (for notifying the client about changes in the tool list); whereas a markdown file doesn't do any of these

3. Could a competent developer sitting at your terminal with what's installed on it do this job? — if yes, that's a skill; even if there were to be a server for the same thing, it'd be a skill, which costs its description until it runs, and a server, which costs its schemas in every session it's connected to, regardless of being used or not

The wrapper server

The most common misconception we come across is the "wrapper server", an MCP server whose every tool calls the CLI the agent already has. A server for git, a server for kubectl, a server for a REST API that ships with its own CLI on your machine already. It's appealing because it feels like a more serious engineering decision, so people keep doing it.

But think about it:

• you need to set up and maintain a process

• every tool comes with a schema in the window of every session that connects with it

• you need to create a config entry on every developer's machine

• you need to align another thing with what's beneath it

While a skill pointing at gh with what to run and what to verify first costs only its description until it runs. So before you consider setting up an MCP server, ask yourself if there's already an authenticated CLI client for the system in question on your machine, and if yes — write the skill

We're not saying that MCP is overhyped (that'd be a stretch), we're saying that when it comes to this particular use case of encapsulating a CLI that's already there on the machine within the protocol, it adds nothing the skill doesn't have and charges rent

Where a skill genuinely cannot go

There are four things a skill can't do that the protocol can:

• credentials — project skills are git files; if you were to instruct the agent to call an API with a token in a skill, you'd end up with the token in git, but if you were to use a server for it instead, it'd stay on the server side and the client would just authenticate against the HTTP transport using a bearer token, API key, or OAuth (which the spec recommends)

• nothing installed locally — if there's an API with an authentication flow and no CLI client anywhere near your machine, you can't create a skill because the skill is just a file telling the agent what to run

• statefulness — the protocol is stateless as of 2026-07-28 (each request comes with its own version and capabilities), but an MCP server can have its state and return a handle for you to revisit a job later; skills are just files

• machine-readable contract — tools come with inputSchema, the JSON Schema describing the shape of their inputs, a type that travels with them; skill instructions are prose the LLM might or might not follow

They compose, and that is the normal case

It's not a "versus" thing, that's composition — this is the normal configuration; the "versus" narrative is mostly a misconception. In every setup we run there's both, splitting one thing — the server for reach, the skill for reasoning

Here's an example:

• we have an MCP server exposing a tool to create an issue

• but it doesn't tell the agent anything about our team's conventions

That we:

• should include the reproduction steps in the body, not the title

• use a specific label for anything connected with billing

• check if there's no duplicate before creating the issue

This is skills territory. We'd write a skill referring to the server's tool, so both the connection and the procedure end up in the context at once. Which also means that:

• our rules are cheaper as skills — a line in a tool description sits in the window of every session that connects with the server, while the same line in a skill body costs nothing in every session that doesn't trigger it

What to check before you install anything

Before you add an MCP server, spend a minute to inventory what's already installed and authenticated on your machine; for most of the clients we work with, it turns out most so-called "integration problems" are git, gh, psql or kubectl. Which means that once somebody gives the agent the procedure, it can operate them via the existing shell tool

After you set up a server, spend another minute to explore what it actually did; every harness here can list the configured servers from the CLI or within the session, some of them even list the tools they expose. Because this number is not trivia — it's the per-session rent you're paying now and the basis to decide if the server was worth its place