MCP Server or Skill? A Decision Rule That Actually Decides.
"Should this be an MCP server or a skill?" is the most common design question in this ecosystem, and most answers are a list of features rather than a decision. Here's the rule we use, and where it breaks.
The rule
**If the agent should call something, build a server. If the agent should know something, write a skill.**
An MCP server exposes typed tools: search_issues(repo, query), create_page(space, title, body). The model picks the tool, fills the arguments, gets a structured result. The capability is a function.
A skill is text loaded into context: how to review a contract, how to structure a deck, which steps to follow in what order. The capability is judgment plus procedure.
The test that resolves most cases: can you describe the thing your agent needs as a function signature? If yes, that's a server. If describing it takes three paragraphs of conditions and exceptions, that's a skill.
Where it breaks
Three cases where the rule needs a second look.
The data is big. "Look up the current price" is a function, but returning a 40MB JSON blob into context is not useful. Servers solve this by computing and returning the answer; skills solve it by adding a script that gets called. Either way, the artifact you want is the answer, not the data — so build whichever lets you compute.
The knowledge is small and the tool is heavy. "Remember our release checklist" does not need a server, a deployment, and an auth story. Paste it in a skill. People reach for servers far more often than they should, usually because servers feel like real software.
You want someone else's capability. A published integration (Jira, a browser, a data provider) is a server someone already runs. Your job there is a skill that uses it well — the server gives you create_page, the skill knows what a good page looks like.
The security difference is the real one
A skill's blast radius is your context and whatever the agent does with the instructions. A server's blast radius is whatever its tools can reach, and the permission prompt is the only thing between a tool call and your data.
That is not an argument against servers — it is an argument for knowing which you are installing. The check is the same one we apply to every skill: compare what the thing promises to what it can reach. A server advertising "read issues" that can also write them has a gap between description and capability, and that gap is the security signal.
What we've actually scored
The MCP-adjacent set is small, and that itself is information — this corner of the ecosystem is young:
mcp-developer(9.1) andmcp-builder(8.6) — the two that help you build a server. The first is the better reference; the second walks the "server or skill?" decision before writing code, which is the right order.atlassian-mcp(9.2) — a worked example of using a shipped integration. It is a skill about operating one product's MCP surface, not about MCP in general.browser-testing-with-devtools(8.8) — drives a real browser through the Chrome DevTools MCP server. The clearest demonstration in our set of an MCP integration doing load-bearing work rather than being a demo.setup-api-key(8.6) — the unglamorous one: configuring credentials for a third-party MCP tool. Worth noting because the boring half of MCP is where most people get stuck.
The full shortlist, with rationale, is at best MCP skills.
The short version
Function signature → server. Conditions and judgment → skill. Mixed → the server fetches, the skill decides what it is for.
And whichever you build: write down what it can reach, then compare that to what you told people it does. The gap between those two sentences is where every problem we have found in this ecosystem lives.