Claude Skills vs MCP Servers: Which to Build First

Skills and MCP servers solve different problems, and confusing them is the most common reason Claude rollouts stall. A skill teaches Claude how your team does something: instructions that load into context only when the task calls for them. An MCP server gives Claude access to something it cannot reach on its own: a running process that exposes tools and live data over a protocol. If you keep pasting the same instructions into chats, you need a skill. If Claude literally cannot see the system you are asking about, you need an MCP server. Most serious deployments need both, wired together deliberately.

This guide gives you the decision framework, the real token and cost differences, the security trade-offs, and a worked example of the two combined.

What a Claude Skill actually is

A skill is a folder on a filesystem. At its root sits a SKILL.md file with YAML frontmatter carrying two required fields: a name and a description. Below the frontmatter, the body is plain Markdown instructions, and the folder can bundle scripts, templates, and reference files alongside it. Anthropic's engineering team describes the format as an onboarding guide for a new hire: procedural knowledge, packaged so an agent can discover and load it dynamically.

The mechanism that makes skills cheap is called progressive disclosure, and it works in three levels:

• Level 1, metadata, always loaded. At startup, Claude pre-loads only the name and description of every installed skill into its system prompt. That is roughly a hundred tokens per skill, enough for Claude to know the skill exists and when it applies, without paying for the full contents.
• Level 2, instructions, loaded when triggered. When your request matches the description, Claude reads the SKILL.md body into context. Only then do the actual steps cost tokens.
• Level 3, resources, loaded as needed. Bundled files such as a reference.md, a schema, or a validate.py are read or executed only when the task calls for them. A script's output enters context; its source code never does.

Because of this design, the amount of knowledge bundled into a skill is effectively unbounded. Anthropic's own PDF skill keeps its form-filling instructions in a separate forms.md file that Claude reads only when it is actually filling a form.

Skills run everywhere Claude runs: claude.ai, Claude Code, the Claude Agent SDK, and the API, with pre-built skills for PowerPoint, Excel, Word, and PDF tasks. In December 2025 Anthropic published Agent Skills as an open standard, so the format is portable across coding agents, not locked to one vendor. Anthropic has since donated the standard to the Agentic AI Foundation under the Linux Foundation, alongside MCP, and more than 70 agent platforms, including ChatGPT, Cursor, GitHub Copilot, and VS Code, have integrated it.

What an MCP server actually is

The Model Context Protocol is an open standard for connecting AI applications to external systems. Anthropic open-sourced it on November 25, 2024, describing it as a universal protocol to replace fragmented, one-off integrations. The official documentation uses a cleaner analogy: MCP is a USB-C port for AI applications.

Where a skill is files, an MCP server is a running process. On connect, it negotiates with the client and declares three kinds of primitives:

• Tools: functions the model can call to act, such as running a query, creating a ticket, or sending a message.
• Resources: data the client can read, such as files, database rows, or API responses.
• Prompts: reusable, parameterized prompt templates the server surfaces.

The client discovers these via tools/list, resources/list, and prompts/list, then issues tools/call when the model decides to use one. Two transports carry the payloads: stdio for local processes and Streamable HTTP for remote servers. Adoption has been fast: thousands of community-built servers, SDKs for every major language, and support across Claude, ChatGPT, VS Code, Cursor, and other clients. A server you build once works across the ecosystem.

The critical point: an MCP server gives Claude genuinely new capabilities and live data it could not otherwise reach. A skill cannot query your production database. An MCP server cannot teach Claude your reporting conventions. They answer different questions. The same capability-versus-procedure split shows up in adjacent features like computer use, where Sonnet 4.6 taking over a real desktop supplies raw ability and skills still have to encode how your team wants that ability applied.

The one-question decision framework

Ask this: does the task need a new capability or live data, or does it need Claude to follow your procedure?

• Capability Claude lacks (call an API, query a database, control a service): MCP server. Only a tool over the protocol can act on an external system.
• Live external data (current tickets, prices, rows, documents): MCP server. Skills are static files; they cannot fetch fresh state on their own.
• Your conventions, format, or playbook (release note format, code review standards, migration runbook): skill. You are shaping the work, not adding a power.
• A repeatable procedure using tools Claude already has (sorting, file conversion, document generation): skill, usually wrapping a script.
• Both a method and a system to act on: both, combined. More on that below.

The blunt heuristic: if you keep re-explaining how to do something, write a skill. If Claude cannot reach the thing you are asking about, connect an MCP server. "Format our release notes this way" is a skill. "Read our open Linear issues" is an MCP server. "Triage our open issues into release notes our way" is both.

One nuance worth knowing: MCP servers can carry their own instructions in the form of tool usage hints and prompts. Anthropic's guidance is to keep those generic. MCP instructions should cover how to use the server and its tools correctly; skill instructions should cover how to use them for your process. If your MCP server says return JSON and your skill says format as Markdown, Claude has to guess which is right. Let MCP handle connectivity; let skills handle presentation, sequencing, and workflow logic.

The token cost difference, with real numbers

This is where the two diverge in a way that hits your invoice, and almost none of the comparison coverage quantifies it.

A skill is nearly free when idle. Only its name and description sit in context, on the order of a hundred tokens. The full instructions cost tokens only when triggered, and bundled files only when read.

An MCP server charges rent whether you use it or not. Most MCP clients load all tool definitions upfront into context the moment a server is connected. Anthropic's engineering blog on code execution with MCP is blunt about what happens at scale: when agents are connected to thousands of tools, they process hundreds of thousands of tokens before they even read your request. A dozen always-on servers quietly shrink your usable context window on every single call.

The second cost is intermediate results. When the model calls MCP tools directly, every result passes through the context window. Anthropic's example: asking an agent to download a meeting transcript from Google Drive and attach it to a Salesforce lead pushes the full transcript through the model twice. For a two-hour sales meeting, that is roughly 50,000 additional tokens, and larger documents can exceed the context window entirely and break the workflow.

Their measured fix is code execution: present MCP servers as code APIs on a filesystem, let the agent load only the tool definitions it needs, and filter data in the execution environment before it reaches the model. In Anthropic's worked example this cut token usage from 150,000 tokens to 2,000 tokens, a 98.7 percent reduction. Cloudflare published similar findings with its "Code Mode" approach.

The practical discipline falls out of the numbers:

• Keep skills plentiful. They are cheap. Fifty installed skills cost you roughly five thousand tokens of metadata, total.
• Connect MCP servers per task, not permanently. Wire up what the workflow needs; leave the rest disconnected.
• Filter before the model. Where your client supports it, aggregate and trim tool results in code rather than dumping raw payloads into context.

Security: two different risk surfaces

Both mechanisms extend what an agent can do, which means both can extend what an attacker can do. The risk profiles are different and your review process should treat them differently.

Skill risks live in the content. A skill is instructions plus optional scripts, so the threats are malicious instructions, prompt injection, unsafe shell commands, hidden helper files, and instructions that direct Claude to exfiltrate credentials or contact untrusted external servers. Anthropic's own guidance: install skills only from trusted sources, and audit anything from a less-trusted source by reading every bundled file, checking code dependencies, and watching for instructions that reach out to the network. The good news is that a skill is fully auditable by reading it. It is a folder of text.

MCP risks live in the access. An MCP server holds credentials, talks to your systems, and can take actions in them. The threats are excessive tool permissions, weak or missing authentication, over-broad data access, and a compromised server becoming a persistent bridge into production. A skill can tell Claude to do something bad; an MCP server can actually do it, at API speed, with whatever token you gave it. Review an MCP server the way you would review a new service account: least-privilege scopes, separate credentials per environment, and a plan for revocation.

The combined pattern compounds both. A skill that orchestrates an MCP server inherits the server's access and adds its own instruction risk, so audit the pair, not the parts. We covered the broader industry reaction to agent capability risk in our piece on Claude Code's security footprint.

The combine pattern: a worked example

The strongest production pattern is a skill that orchestrates an MCP server's tools. The server supplies raw capability; the skill supplies judgment. Anthropic uses the same pattern in its own finance skills: a comparable company analysis skill defines the methodology, valuation approach, and compliance formatting, while MCP connections to S&P Capital IQ, Daloopa, and Morningstar supply the live market data.

Here is a smaller version you can build this quarter. Say your operations lead wants a weekly revenue report. You connect a database MCP server exposing run_query and list_tables. On its own, Claude can now query, but it has no opinion about your reporting conventions. The skill closes the gap:

---
name: weekly-revenue-report
description: Generate the weekly revenue report. Use when asked for the
  revenue report or weekly numbers. Requires the database MCP server.
---

When asked for the weekly revenue report:
1. Call list_tables to confirm orders and refunds exist.
2. Query gross revenue and refunds for the last 7 full days, grouped by day.
3. Net equals gross minus refunds. Flag any day down more than 20 percent week over week.
4. Render the house format: Date, Gross, Refunds, Net, WoW percent.
5. Post the summary to the finance Slack channel via the Slack MCP server.

Notice what each half contributes. The MCP servers know nothing about your flagging thresholds or house format. The skill cannot reach the database or Slack. Together they produce exactly what your team expects, the same way every week. And because the skill only loads when someone asks for the report, the whole capability costs you nothing on unrelated tasks.

The same shape applies elsewhere: a code-review skill driving a GitHub MCP server, a meeting-prep skill driving a Notion connection (Notion ships exactly this as its Meeting Intelligence skill), a KYC-review skill driving a document store. Build the capability once as a server; encode each recipe as a skill.

Common mistakes

• Building an MCP server to wrap a workflow. If the deliverable is a procedure and Claude already has the underlying capability, a server is the wrong artifact. One practitioner who shipped six skills found the gh CLI plus a skill beat the GitHub MCP server so cleanly he stopped using the server; fixes to a skill mean editing a script, while fixes to a server mean touching tool contracts, resource URIs, and client compatibility.
• Writing a skill that fakes access. A skill full of instructions about your database schema cannot run a query. If the agent needs live state, give it a connection.
• Vague descriptions. The description is the trigger. If Claude cannot tell when the skill applies, it never loads, and you have written documentation nobody reads. This is the number-one failure mode in practice.
• Connecting every MCP server permanently. Each connected server injects its tool definitions into every call. Ten servers you use weekly cost you context on the nine you are not using right now.
• Conflicting instructions between server and skill. JSON from the server hints versus Markdown from the skill means Claude guesses. Assign ownership: connectivity to MCP, presentation and sequencing to the skill.
• Skipping the audit on third-party artifacts. A registry skill is a folder of instructions someone else wrote; a community MCP server is a process holding your tokens. Read the first, scope the second.

A decision checklist

Before building either, walk this list:

• Can Claude already do the core task with tools it has? If yes, write a skill.
• Does the task need live data or actions in an external system? If yes, you need an MCP server for that part.
• Will more than two people or more than one workflow reuse this? If yes, the packaging effort pays back.
• Have you written the skill description as a trigger, with the task names people actually say out loud?
• Have you counted the context cost of every always-on server, and disconnected the rest?
• If combining: does the skill own sequencing and formatting, and the server own connectivity, with no overlapping instructions?
• Have you read every file in a third-party skill, and scoped every token you hand to a third-party server?

Frequently asked questions

Do skills replace MCP? No. MCP provides connectivity to external tools and data; skills provide procedural knowledge for using that connectivity well. The strongest workflows use both, and Anthropic's own documentation says so explicitly.

Can one skill use multiple MCP servers? Yes. A single skill can coordinate several servers at once, for example pulling internal research from Google Drive, competitor repositories from GitHub, and market data from a search connection, then applying your analysis methodology to all of it.

Are skills and MCP servers locked to Claude? Neither is. MCP is an open standard supported by ChatGPT, VS Code, Cursor, and many other clients, so a server you build works beyond Claude. The Agent Skills format was published as an open standard in December 2025 and is now governed by the Agentic AI Foundation, with integrations across more than 70 agent platforms.

Which costs more in tokens? MCP servers, by a wide margin. A skill's idle cost is its metadata, roughly a hundred tokens. A connected MCP server's tool definitions load into every call whether used or not, and intermediate tool results pass through the model's context unless you filter them in code first.

What should we build first? Start with the skill. It is a folder of Markdown, auditable in an afternoon, and forces you to write down the procedure, which is the part most teams have never formalized. Add MCP servers only for the systems the procedure genuinely needs to touch.

Can Claude write its own skills? Yes, and Anthropic recommends it. After a successful session, ask Claude to capture the approach and the mistakes into a reusable skill. Iterating this way surfaces the context the agent actually needs instead of what you guessed upfront.

Where to go from here

If your team is past the pilot stage, the real work is not choosing between skills and MCP but building the library: the dozen skills that encode how your firm reviews, reports, and delivers, plus the handful of well-scoped servers that connect Claude to the systems of record. That library is what turns a general-purpose model into something that behaves like a trained colleague. Our Claude implementation service covers exactly this: Claude Code and Cowork rollout, MCP server selection and hardening, and a skills library built around your procedures. For always-on deployments where the agent runs continuously rather than per-session, see how our AI Employees use the same skill format on the open-source Hermes agent. And if you are still weighing Anthropic's enterprise direction against the alternatives, our analysis of Claude's enterprise plugin strategy and the workplace AI race will give you the context.