You are building an agent. You want it to follow your team's deployment checklist, and you want it to write a row to Postgres when the deploy finishes.
Two mechanisms are available and the docs describe both accurately without telling you which one to reach for. So people reach for MCP, because MCP arrived first and has more written about it, and end up building a server whose only job is to return a paragraph of instructions.
That works. It is also the wrong tool, it costs a process, a transport and an auth surface, and it burns context on every single call.
There is a one-line rule that resolves almost every case.
The rule
A Skill teaches the agent how to do something. An MCP server lets the agent do something it otherwise could not.
Instructions, conventions, checklists and process knowledge go in a Skill. Live tool execution against a system the agent has no other route to goes in an MCP server.
Everything below is why that line sits where it does, and the cases where it genuinely blurs.
What each one actually is
A Skill is a folder on disk. Markdown instructions, optionally with scripts and reference files beside them. The agent reads the descriptions, decides which are relevant to the task in front of it, and loads the full contents only then. It is instruction, not capability: a Skill cannot reach anything the agent could not already reach.
An MCP server is a running process. It advertises a set of tools with input schemas, the agent calls them, the server executes and returns a result. It is capability, not instruction: it can write to a database, hit an internal API, read a file on a machine the agent has no shell on.
The clean way to hold it: MCP is the port. A Skill is the manual. One gives the agent reach, the other gives it judgement.
A Skill cannot do anything the agent could not already do. That single sentence resolves most of these arguments.
Why the distinction is worth caring about
If it were only architectural taste it would not matter. It shows up in three places that cost you real money and reliability.
Context. An MCP server's tool definitions are loaded into context up front, on every call, whether or not the agent needs them. Connect several servers with a dozen tools each and you have spent a meaningful slice of the window before the task starts, and tool selection gets worse as the list grows. A Skill is progressively disclosed: the agent sees a one line description, and only pulls the body in when it decides the Skill applies.
Operations. A server is a process to run, a transport to configure, credentials to store and rotate, and a thing that can be down. A Skill is a folder in a repository. It has no uptime.
Auditability. This cuts the other way. Every MCP tool call is a discrete, logged, schema-validated event with a result. That is exactly what you want for anything that mutates state. Instructions in a Skill produce no such record.
The comparison
| Skill | MCP server | |
|---|---|---|
| What it is | Files on disk, loaded on demand | A running process exposing tools |
| Gives the agent | Judgement and process | Reach into other systems |
| Context cost | Only when the agent loads it | Tool definitions loaded up front, every call |
| Can it write to a database | Not on its own | Yes, that is the point |
| Auth surface | None of its own | Credentials, transport, tokens |
| Fails when | The instructions are wrong | The process is down |
| Audit trail | None inherently | Every call, schema-validated |
| Right for | Conventions, checklists, house style, domain rules | Live data, mutations, internal APIs |
The cases where it genuinely blurs
Three real ones, with the answer.
"I need the agent to read our API docs." Skill. Docs are instruction. Put the markdown in a Skill folder and let it load on demand. You do not need a server to hand back a document that never changes between calls.
"I need current data from our database." MCP. A Skill cannot query anything. Even if you write perfect SQL into the Skill body, something has to execute it.
"I need both: query the database, then format the result to our house standard." Both, and this is the common shape. The MCP server returns rows. The Skill carries the formatting rules, the naming conventions, the thing your team argues about in review. Neither does the other's job and neither is redundant.
A useful test when you are unsure: would this still be correct if written down in a document and handed to a new engineer? If yes, it is a Skill. If it requires running something to find out, it is MCP.
Would this be correct written in a document and handed to a new hire? If yes, it is a Skill. If you have to run something to find out, it is a server.
A worked example
The blog you are reading runs on this split, and it is a fair illustration because the two halves are obvious.
The MCP half. A scheduled agent researches topics daily and inserts them into Supabase. That needs a live connection: it queries existing rows so it never files a duplicate, then writes new ones. No amount of instruction achieves that, something has to hold a connection and execute SQL. It goes through the Supabase MCP connector, and deliberately not through a key committed anywhere in the repository.
The Skill half. What makes a good post here is a document: the tone, the banned vocabulary, the structure, the rule that comparison tables put the verdict in the last column, the rule against em dashes. None of that requires execution. It is instruction, it changes when we learn something, and it belongs in a file the agent reads when it is writing rather than in a tool definition loaded on every unrelated call.
Same agent, same task, two mechanisms, no overlap.
Common mistakes
Building an MCP server that returns instructions. The most frequent one. If the tool takes no meaningful input and returns the same text every time, it is a document wearing a schema. Move it to a Skill and delete the server.
Connecting every server you have, all the time. Tool definitions occupy context whether used or not, and a long tool list measurably degrades selection. Connect what the current job needs.
Putting credentials in a Skill. A Skill is a folder, often in a repository, often shared. Secrets belong in the server's configuration or a vault, never in instruction files.
Assuming Skills are just prompts. They are progressively disclosed and can ship executable scripts and reference files alongside the markdown. That is closer to a loadable module than to a system prompt.
Reaching for MCP because there is more written about it. MCP arrived first and has the larger ecosystem, which makes it the default answer in most search results. Default answers are not the same as correct ones.
Key takeaways
- A Skill teaches the agent how to do something. An MCP server lets it do something it otherwise could not.
- A Skill cannot reach anything the agent could not already reach. If execution is required, you need a server.
- MCP tool definitions load into context up front on every call. Skills load only when the agent judges them relevant.
- Anything that mutates state belongs in MCP, because every call is discrete, schema-validated and logged.
- Conventions, checklists, house style and domain rules belong in a Skill, because they are documents.
- The test: would this be correct written down and handed to a new engineer? If yes, Skill. If you must run something to find out, MCP.
- Complex agents use both. The server supplies live data, the Skill supplies the judgement about what to do with it.
If you want the plumbing rather than the theory, our guide to connecting n8n to MCP servers walks through a real setup including the transport choice that silently breaks. And if you are still choosing what to wrap around the model, we compared the Claude Agent SDK, LangGraph and OpenAI Agents SDK on production behaviour.
