Claude Skill or MCP Server? The Question That Decides Distribution

I'm deciding whether to package [describe what you're building] as a
Claude Skill or an MCP server. Walk me through this decision rule before
I write either:

1. Does more than one person, machine, or non-Claude tool need this?
   If yes, weight toward MCP server.
2. Does it need to hold state across calls, or reach a live system
   (a database, an API session) rather than just reformat a prompt?
   If yes, weight toward MCP server.
3. Am I the only user, on one machine, and is this purely a set of
   instructions for how to do something Claude can already do with its
   existing tools? If yes, weight toward Skill.
4. Do I have anywhere to host and maintain a server, and does the
   calling session's own permissions need to be constrained separately
   from what the server can touch? If no hosting and no separate trust
   boundary needed, weight toward Skill.

Recommend one, say why, and scaffold it.

Problem#

A Claude Skill and an MCP server both extend what Claude can do, and it is easy to reach for whichever one you built last time instead of the one the situation calls for. Pick a skill for something a team needs to share and it quietly turns into a folder someone has to remember to copy every time it changes. Pick a server for something only you use on one machine and you have taken on hosting and auth for no reason. The distinction that matters is not what each one does for you today. It is what happens when you need to update it or hand it to someone else.

Pattern#

A Skill is a folder of instructions, typically a SKILL.md plus optional scripts, that Claude loads and follows. It is prompt-layer, not capability-layer: a skill does not give Claude a new tool, it gives Claude better instructions for using the tools it already has. Because it runs in-process, it inherits whatever permissions the current session already has, the same file access and the same approval prompts, with no separate trust boundary to configure.

That local, in-process design is also the whole problem:

• Skills live on one machine. A user-level skill sits in ~/.claude/skills. A project-level skill in a repo’s .claude/skills at least reaches everyone working in that repo, but no further. There is no registry and no “install this skill” command that reaches a team by default.
• Distribution is manual and single-vendor. Sharing a skill means copying the folder, pasting it into Slack, or telling someone to pull the repo. Even then it only means something to Claude’s own tools: a skill written for Claude Code is not portable to a different agent, because it is a client-specific instruction format, not a shared standard.
• Updates do not propagate. Fix a skill and only your copy changes. Everyone else keeps running the stale version until they notice and manually re-sync. There is no version number and no out-of-date signal, just however many forked copies happen to exist across machines. Plugin marketplaces help a little with an install/update flow, but the baseline is still a file on disk, not a service.

An MCP server is a running service that speaks the Model Context Protocol, a boundary separate from whatever client is calling it. It solves the distribution problem structurally, because there is nothing to copy:

• Distribution becomes a URL. Host the server once, internally or in the cloud, and every client points its config at it. No folders, no per-machine setup past the first connection.
• Updates reach everyone at once. The logic lives server-side, so deploying a new version changes behavior for every connected client on its next call. One source of truth instead of N forked copies.
• It is cross-vendor by construction. MCP is an open protocol, not a Claude-only format. Other vendors’ clients can speak it too, so a server built once can serve Claude and any other MCP-compatible agent, which is as large a distribution win as the update story.
• It is its own trust boundary. A server carries its own auth, API keys, OAuth, scoped permissions, rather than inheriting the calling session’s access. That is more deliberate about what a caller can touch, and it is also infrastructure someone has to run, secure, and keep online, where a skill has none of that to maintain.

The two compose rather than compete: a skill’s instructions can simply tell Claude to call an MCP tool as one step in its workflow.

Output#

The decision rule in the Shortcut prompt above is the reusable part: weigh who else needs it, whether it needs state or a live system, and whether hosting and a separate trust boundary are worth taking on. A single-user instruction set with no external state stays a Skill. Anything more than one person, one machine, or one client needs to reach becomes an MCP server, because that is the only one of the two with a real answer for “how do I update everyone.”

Variations#

• Already maintaining a Skill that a second teammate now needs? That is the signal to promote it: wrap the same instructions as an MCP server that exposes them as a resource or a prompt, the same three-way choice the voice-rules cheat sheet’s own Shortcut prompt already asks Claude to reason through.
• A skill can stay a skill and still call out to a server for the parts that need real state, for example a lookup against a live database, instead of being rebuilt as a server in full.
• If the only reason you are hesitating on a Skill is “what if someone else needs this later,” a project-level .claude/skills entry checked into the repo is a reasonable middle ground before the jump to a hosted server.