Agent skills or MCP servers: which do you need

Access or know-how

If the model cannot reach the thing it needs, such as your issue tracker, a database or a folder of documents, you need an MCP server, because a server is the program that provides that access. If the model can already reach what it needs but keeps doing the task badly or inconsistently, you need a skill, because a skill is written instructions that tell it how. Many setups end up with both: the server opens the door and the skill explains what to do once inside.

The difference that matters most for safety follows from that. A server holds a credential and acts on a real system. A skill holds text.

What each one is made of

A server is a running process. It declares tools, the client offers them to the model, and calls go through the server to whatever it connects to. It needs installing, configuring and usually a key. It can break when the API behind it changes.

A skill is a file, usually called SKILL.md, with a short description at the top and guidance below. The model reads the description to decide whether the skill applies and loads the rest when it does. Nothing runs, nothing connects, and there is no key to hand over. The skills directory keeps skills in a separate table from servers and has no credential column for them, because there is nothing to put in it.

Three situations, three answers

A team wants an assistant to write up new tickets every morning. The model has no way to see the tracker, so the first need is a server for it, given a read-only token for the one project. A skill may follow later, describing the summary format the team likes.

A developer's coding agent already edits files and runs tests, but writes commit messages in a style the team keeps correcting. Nothing new needs reaching. A skill that sets out the house style, with a few examples, fixes this without adding any access.

The test for which case you are in is simple to run. Ask the model to do the task while you paste in by hand the data it would need. Good work with the data in front of it means the gap is access, and a server closes it. Bad work even then means the gap is instructions, and no server will fix that.

An analyst wants answers from a warehouse and keeps getting queries that ignore how the tables join. The server for the warehouse is already connected. What is missing is knowledge of the schema and the business rules, which is a skill's job. Adding a second database server would add risk and fix nothing, while a few paragraphs describing the joins and the rules would fix it.

Where the line blurs

A skill can tell a model to run commands or call tools that a server or the client already provides. At that point the skill is steering real actions, even though it holds no key itself. Read those parts of a skill as carefully as you would read a server's tool list.

Servers can also ship prepared prompts, which overlap with what a skill does. The practical difference is where they live and who maintains them: a server's prompts come with its code and its author, a skill sits in your own folder and you can edit it freely.

Choosing in practice

Start by writing down what the model cannot currently see or do. Each item on that list is a candidate for a server, and each server is a credential decision. The post on what credentials expose covers how narrow that key can be.

Then write down what it does wrong with what it can already reach. Each of those is a candidate for a skill, and often a short one written by you will beat a long one written for someone else's project. The MCP server directory and the skills directory sit side by side for this reason: the same decision, seen from its two sides.

Costs that come with each

A server is a running dependency. It needs updating when the API behind it changes, its key needs rotating, and when it breaks the model loses a capability until someone fixes it. Each server is also a set of tool descriptions the model reads on every request, so adding servers that are rarely used makes the model's choice harder for everything else.

A skill costs less to keep. It has no process, no key and no API to drift away from. Its maintenance is editorial: when your conventions change, the skill has to change with them or it will teach the model last year's habits. A stale skill fails quietly, by producing output that looks fine and follows rules nobody uses any more.

Both are cheapest when they are small and specific. A server that wraps one API narrowly and a skill that covers one task precisely are easier to reason about, easier to replace, and less likely to fire when they should not.

There is a quieter cost too. Every tool description and every skill description is text the model reads before it starts, and that text takes up room the task itself could have used. A setup with a few well-chosen pieces leaves the model more attention for the work you asked for than one with everything installed just in case.