Agent skills vs MCP servers vs rules files: what each one costsSkip to content

LOADED ON DEMAND<br>CONNECTED ALL SESSION<br>IN EVERY CALLThe three channels ordered by how permanently the harness wires them in, which is the same order as what they cost on a turn that never uses them.←Back to all field notesPublished03.08.20269 min<br>Share or discussXinghCopy link

You want your agent to stop writing migrations the wrong way. There are three places you could put that, and no obvious reason to pick one. You can write it into AGENTS.md. You can package it as a skill. You can stand up an MCP server that exposes a migration tool. Every guide I have read on this answers a different question than the one I have, which is not what are these things but what does each one cost me on the four hundred turns where it never gets used.

That cost is real and it is invisible. A capability you deliver the wrong way does not error. It sits in the window, quietly taking room from the task, and you find out later when the agent starts skimming the thing you most needed it to read.

NAME AND DESCRIPTION<br>TASK MATCHES<br>BODY LOADS<br>FILES RUNA skill is read in stages, so the cheap part is what the agent carries around and the expensive part only arrives when a task actually matches.<br>The three channels, quickly

I am not going to re-derive what belongs in a rules file. That argument already has a home in where your decisions should actually live, and the short version is that rules files carry operational facts about the repo, not product decisions.

A rules file (AGENTS.md, the open standard defined at agents.md, or a vendor file like CLAUDE.md) is text the harness reads and puts in front of the agent. It is always there. That is the whole point of it and also the whole problem with it.

A skill is a folder with a description and a body. The harness shows the agent the descriptions of everything available, and pulls in the body only when a task looks like a match. Anthropic describes the general pattern in their writing on context engineering, where agents keep lightweight identifiers around and fetch the real content when they need it rather than pre-loading everything up front.

An MCP server is a running process the agent talks to over a protocol. It is not text at all, it is a live connection with real tools behind it, which is why it can hold credentials, hit a database, or return something that was true one second ago. The current spec made the protocol stateless at its core and added a server/discover method so clients can fetch server capabilities when they want them up front.

The split is not only mine. When GitHub made both generally available in Copilot code review, it drew the same line: skills carry your team’s internal tools and coding standards as SKILL.md files in the repo, while MCP connections pull context from third-party platforms like issue trackers and service catalogs.

Three different mechanisms. The interesting part is not the taxonomy, it is what happens to each one on a turn where the task has nothing to do with it.

When it loads is the whole question

Connect a handful of MCP servers and look at what your agent is carrying before you have typed a task. Every tool from every connected server, each with a name, a description and a schema, described well enough for the model to choose between them. That inventory goes with the request. It is there on the turn you use the database tool and it is there on the four hundred turns you do not.

The same is true of a rules file, and that part is already documented in this cluster: every line the harness auto-loads is spent on every call. What I want to add is that the rule generalizes. Anything the harness wires in permanently is paid for permanently, and MCP servers are the most expensive version of it because the tool list grows with every server you connect and nobody prunes it. Context is a finite resource whatever you spend it on, and this is a bill you agreed to without reading.

A skill is the only one of the three with a cheap idle state. The agent carries the description and nothing else until a task matches. You can have a hundred skills installed and pay almost nothing for the ninety-nine that are irrelevant right now.

ChannelWhen it loadsCost on an unrelated turnHow it failsRules filealways, every callthe whole filegoes stale and misleadsMCP serverconnected all sessionevery tool descriptioncrowds out the task, or the process diesSkillon demand, when matchedthe description onlynever gets picked<br>That last column is the one people skip, and it is where the choice actually bites.

Each one fails in its own way

A rules file fails by aging. It keeps saying something that stopped being true, nothing throws, and the agent follows it with total confidence. That failure mode has its own piece in your rules file is lying to your agents, so I will leave it there.

A skill fails at the door. The agent never sees the body, so the failure is invisible from inside the...