Guide

When should you build a Claude Skill instead of an MCP server

Published 29 September 2026

Ask one question: does the thing you want to add require reaching outside the model's environment? If it does, that is a server. If it is knowledge, a procedure, or a house style, that is a Skill.

Most of what teams want to add turns out to be the second kind. Procedure is a file. Reach is a running program.

The two official trigger sentences

Pasting instructions means you want a Skill. Pasting data out of another system means you want a server.

The Claude Code skills page has no side-by-side Skill versus MCP comparison section, so if you have seen one quoted, check the page before you rely on it. What the docs do give you is a trigger sentence for each, on two separate pages, and the two are close to opposites.

For Skills, the Claude Code docs say: "Create a skill when you keep pasting the same instructions, checklist, or multi-step procedure into chat, or when a section of CLAUDE.md has grown into a procedure rather than a fact."

For servers, the Claude Code MCP page says: "Connect a server when you find yourself copying data into chat from another tool, like an issue tracker or a monitoring dashboard."

The contrast that follows is assembled from those two definitions, not lifted from a page that compares them.

What each one actually is

A Skill is instructions, metadata and optional resources on the filesystem, with nothing to deploy and no process to keep alive. An MCP server hands the model callable functions and data.

The Agent Skills overview page calls Skills "reusable, filesystem-based resources that give Claude domain-specific expertise: workflows, context, and best practices that turn a general-purpose agent into a specialist." Each Skill packages instructions, metadata, and optional resources such as scripts and templates, which Claude uses automatically when relevant.

Instructions, metadata, optional resources. Nothing to deploy, no endpoint to expose, no process to keep alive.

The Model Context Protocol specification lists what a server offers a client: "Resources: Context and data, for the user or the AI model to use; Prompts: Templated messages and workflows for users; Tools: Functions for the AI model to execute." A server hands the model callable functions and data, not your judgment. The platform docs put it from the other direction: "Claude does not call an MCP tool for general knowledge questions about a connected service."

The cost asymmetry, which should be your default tiebreaker

A Skill costs close to nothing to run until it fires. An MCP server is software you own, along with what the spec requires of it and the version churn.

A Skill is a file. Every Skill requires a SKILL.md with YAML frontmatter, and only two fields are required: name and description. The name is capped at 64 characters, the description at 1024, and the description "must include both what the Skill does and when Claude should use it." In Claude Code the folder goes in ~/.claude/skills/ for you, or .claude/skills/ for the project, with no API upload.

Its running cost is close to nothing until it fires. The Agent Skills page describes progressive disclosure in three levels:

  • The name and description, always loaded at startup at roughly 100 tokens per Skill.
  • The SKILL.md body, under 5k tokens, loaded only when the Skill triggers.
  • Further resources that cost nothing until accessed.

An MCP server is software. Under stdio the client launches it as a subprocess; under Streamable HTTP, per the spec, it operates as an independent process that can handle multiple client connections, which means you own a service. The spec is explicit about the bill:

  • Servers MUST validate the Origin header to prevent DNS rebinding attacks.
  • Servers SHOULD bind only to localhost (127.0.0.1) rather than all interfaces (0.0.0.0) when running locally.
  • Servers SHOULD implement proper authentication for all connections.

You also own the version churn. The current revision is 2026-07-28, and its Streamable HTTP page announces that the revision changed that transport's behavior, removing the GET stream endpoint and protocol-level sessions; the versioning page now states flatly that there is no negotiation handshake. Anything you shipped against an older revision is your backlog.

A rough sorting test

Checklists, formats, procedures and explanations are Skills. Reading your tracker, querying your database or writing into an internal system is a server.

What you want to add Build
Your code review checklist Skill
The house format for a release note Skill
The multi-step procedure for onboarding a client Skill
An explanation of how your tracker's workflow states work Skill
Reading open issues out of your tracker Server
Querying your production database Server
Writing a row into an internal system Server

The fourth row is the one people get wrong. Knowledge about your tracker is a Skill. Reading your tracker is a server.

The Claude Code skills page also states: "Custom commands have been merged into skills." If you were weighing a slash command as a third option, there is no longer a third option.

The common real answer is both

The most useful shape is usually a Skill that knows when and how to use a server. The server exposes the callable functions; the Skill carries the judgment about when they get called, in what order, and what to do with the result.

The spec defines the mechanism and stops there. It says tools are "model-controlled, meaning that the language model can discover and invoke tools automatically based on its contextual understanding and the user's prompts." Contextual understanding is exactly what a Skill supplies and exactly what a bare tool list does not.

The docs are organised around that composition rather than a rivalry: the Claude Code skills page has a section on running skills in a subagent, and the subagents page has sections on scoping MCP servers to a subagent and on preloading skills into subagents. The MCP spec landing page even names Skills over MCP among its optional extensions.

If you are still torn, write the Skill first. It is cheap and reversible, and it will tell you quickly whether the gap that remains is genuinely a reach problem.

Where this fits if you use Bespoke Prompting

Bespoke Prompting's MCP Tool build type applies a narrower version of this discipline before it writes a spec. Its classification is deterministic, tool_count is derived as one on the doctrine of one callable tool doing one job, and it flags contradictions rather than building around them: reads_as_agent when the request actually describes an autonomous agent rather than one callable tool, and multi_tool_implied when more than one tool is implied and a multi-tool server should be recommended instead. The point is the same one this article makes: name what the thing actually is before you build the wrong shape of it.

Sources

Suggested internal links