Skills vs. MCP servers vs. prompts: what goes where
Every team extending an AI coding agent ends up juggling three mechanisms: prompts, MCP servers, and skills. They get discussed as if they compete. They don't — they answer three different questions.
- A prompt answers: what do I want right now?
- An MCP server answers: what can the agent reach?
- A skill answers: how do we do things here?
Confusing them produces either bloated prompts doing a skill's job, or MCP servers built for things a markdown file could carry. Here is the honest comparison.
Prompts: intent, not knowledge
A prompt is a message in one conversation. It is the right place for the specifics of this task — "rename the flag, keep backward compat, don't touch the tests yet". It is the wrong place for anything meant to persist: pasted process instructions die with the session and drift with every re-paste.
The tell that you've outgrown a prompt: you keep a text file of "good prompts" and paste from it. That file wants to become skills.
MCP servers: capability with a runtime
The Model Context Protocol connects agents to live systems — your database, your issue tracker, your CI. An MCP server is software: it runs as a process, holds credentials, exposes tools the agent can call mid-task.
That power has a cost profile. Someone builds the server, someone runs it, someone secures the credentials it holds. That cost is justified when the agent needs to do something it fundamentally can't do with text — query production data, create a ticket, trigger a deploy. It is wasted when the payload is knowledge. Your architecture conventions do not need a port and a process; they need a well-written document the agent loads at the right moment.
Skills: procedure and judgment as files
A skill is a folder — SKILL.md plus references — that the agent loads when a task matches its description. No runtime, no credentials, no infrastructure. Skills carry the material that makes an agent behave like your engineer instead of a generic one: review standards, release procedures, naming rules, the exceptions and "never do X" boundaries that constitute institutional judgment.
Because they are files, skills inherit the entire toolchain civilization already built for files: diff, review, versioning, packaging, distribution.
The comparison, compressed
| Prompt | MCP server | Skill | |
|---|---|---|---|
| Carries | intent | capability | knowledge & procedure |
| Lifetime | one conversation | while running | permanent, versioned |
| Infrastructure | none | process + credentials | none |
| Authored by | anyone, ad hoc | developers | anyone who owns the process |
| Distribution | copy-paste | deployment | files → registry |
They compose
The strongest setups use all three at once. A release skill instructs: check CI, verify the changelog, tag, deploy, announce. The MCP servers provide the hands: the CI status tool, the deploy trigger. The prompt supplies the specifics: "release 2.4, skip the announcement". Remove the skill and the agent improvises your process; remove MCP and it can't act; remove the prompt and it doesn't know what you want today.
A rule of thumb
If it's about this task, put it in the prompt. If the agent must touch a live system, build MCP. Everything else — how your team decides, reviews, ships, and names things — is a skill.
One practical consequence: because skills are just files, the barrier isn't technical, it's organizational — keeping fifty of them current across a team is the real problem. That's the layer MasterSkills covers: a private registry that versions your skills and installs them into every coding agent your team uses. The prompts stay yours; the MCP servers stay with your infra team; the knowledge finally gets a home.