MCP Servers vs Agent Skills: Which to Build in 2026

Last updated: July 2, 2026

You are adding a capability to an agent. Say you want it to open pull requests, or file expense reports, or format every report your team ships the same way. The question that stops most teams is not "can the model do this" but "what should this capability actually be." An MCP server? An Agent Skill? Both? They look adjacent, they get pitched as competitors, and the wrong choice leaves you maintaining a service when a folder would have done, or hand-rolling brittle instructions when a real connection was the answer.

They are not competitors. They answer different questions. An MCP server answers "what can this agent reach," and a Skill answers "how should this agent do the work." Once that line is clear, the decision is mostly mechanical. Here is the framework, grounded in the primary sources, plus the cases where you genuinely want both.

What MCP Actually Is

The Model Context Protocol is, in Anthropic's own words, "an open protocol that enables seamless integration between LLM applications and external data sources and tools," providing "a standardized way to connect LLMs with the context they need" (see the specification). The key word is protocol. MCP is a wire format, not a feature.

Architecturally it is JSON-RPC 2.0 between three roles: a Host (the LLM app that initiates a connection), Clients (connectors inside the host), and Servers (the services that expose capabilities). The spec explicitly notes it was inspired by the Language Server Protocol, and the analogy is a good one. Just as LSP lets any editor talk to any language backend, MCP lets any compatible agent talk to any server, with stateful connections and capability negotiation at setup.

A server can expose three primitives, defined in the spec as:

• Resources - context and data for the user or model to use
• Prompts - templated messages and workflows
• Tools - functions the model can execute

Servers talk over one of two standard transports. stdio launches the server as a subprocess and exchanges newline-delimited JSON-RPC over stdin and stdout; the spec says clients "SHOULD support stdio whenever possible." Streamable HTTP uses a single endpoint with POST and GET, optional SSE streaming, and session management via an MCP-Session-Id header. That transport replaced the older HTTP+SSE design from the 2024-11-05 revision. The current stable spec is dated 2025-11-25, and if you want the details of what changed, the changelog is the primary source.

One direction matters for a 2026 decision: the next revision, a release candidate dated 2026-07-28, is headlined by making MCP stateless at the protocol layer. If you are building a server today, that is the trend to build toward, and it is covered in the stateless migration guide.

The through-line: an MCP server is access to a system. It is a connection, with auth, sessions, and callbacks. If you are new to the concept, the beginner guide to MCP servers and the complete guide cover the ground before this decision.

What Agent Skills Actually Are

A Skill is something else entirely. Anthropic's docs define Agent Skills as "modular capabilities that extend Claude's functionality," where "each Skill packages instructions, metadata, and optional resources (scripts, templates) that Claude uses automatically when relevant." The framing they use repeatedly is onboarding: a Skill is "like an onboarding guide you'd create for a new team member."

The open standard puts it structurally: "At its core, a skill is a folder containing a SKILL.md file. This file includes metadata (name and description, at minimum) and instructions that tell an agent how to perform a specific task. Skills can also bundle scripts, reference materials, templates, and other resources." The SKILL.md frontmatter requires only name (max 64 characters, lowercase, hyphens) and description (max 1024 characters), and the docs stress the description "should include both what the Skill does and when Claude should use it."

The design center is progressive disclosure, and the token math is what makes it work. Anthropic's docs lay out three levels:

• Level 1 - Metadata: always loaded at startup, roughly 100 tokens per Skill, just name and description. As the docs put it, "you can install many Skills without context penalty; Claude only knows each Skill exists and when to use it."
• Level 2 - Instructions: the SKILL.md body, under about 5k tokens, loaded only when the Skill is triggered. "Only then does this content enter the context window."
• Level 3+ - Resources and code: effectively unlimited bundled files, read or executed on demand. Scripts run via bash and return only their output, so, per the docs, "the script code itself never enters context."

That last property is the quiet superpower. A Skill can ship a 2,000-line reference doc and a data-processing script, and none of it costs context until the moment the agent actually needs it.

Skills are also portable. The format "was originally developed by Anthropic, released as an open standard, and has been adopted by a growing number of agent products," including Claude Code, Cursor, Gemini CLI, GitHub Copilot, OpenAI Codex, Goose, and Letta. Build one folder, run it across compatible agents. If you have never built one, start with the beginner guide to Claude Code skills.

The through-line: a Skill is how to do a task. It is procedural knowledge plus bundled resources, loaded into the agent you already have. Nothing new connects.

The Real Distinction, In One Line

MCP gives the agent a new thing it can reach. A Skill gives the agent expertise about work it already does.

That is the whole framework. A server is a live capability behind a connection. A Skill is static know-how that flows into context on demand. Everything else in the decision falls out of that difference, and this site has argued the practical side of it before in skills over MCP for progressive disclosure and the closely related Claude agents vs skills breakdown.

Head to Head

The rows on auth, state, and live data are what usually decide it. If the capability needs to talk to a running system, hold a session, or authenticate a user, no amount of markdown replaces a server.

The Decision Framework

Walk these five questions in order. The first "yes" that forces a server usually settles it.

1. Does it need a live connection to a running system? If the capability queries a database, hits a third-party API in real time, or reads state that changes minute to minute, you need a server. A Skill ships static files; it cannot maintain a session or stream fresh data. This is the cleanest MCP signal.

2. Does it need auth or per-user scopes? MCP has a built-in authorization model: OAuth, incremental scope consent, remote endpoints. Skills have no auth concept. If a human has to grant access to their account, that is server territory.

3. Is the capability mostly procedure and judgment? If what you are encoding is "how our team writes a postmortem," "the steps to cut a release," or "the house style for a report," that is a Skill. It is knowledge, not a connection. The why skills beat prompts argument applies here: durable procedure belongs in a loadable Skill, not a sprawling system prompt.

4. How much reference material rides along, and how often is it needed? Progressive disclosure makes Skills ideal for large but occasional context: a long API reference, a lookup table, a template library, a validation script. It sits at zero context cost until the moment it is relevant. Cramming that into an always-connected server means paying for it on every request.

5. Who else needs to consume it, and how do you ship updates? A server is a deployment: you version it centrally, and every client picks up the change by reconnecting. A Skill is a folder: portable, version-controlled, and runnable across any compatible agent, but you distribute copies rather than updating one live endpoint. If ten teams need the same live capability, a server centralizes it. If ten teams need the same playbook, a Skill travels well but you own the sync.

If none of questions one, two, or three forces a server, default to a Skill. It is lighter, cheaper in context, and portable. Reach for a server when the capability is fundamentally a connection.

When You Want Both

This is the case the "vs" framing hides, and it is the one Anthropic actually documents. In the Agent Skills announcement, the engineering team writes that they "explore how Skills can complement Model Context Protocol (MCP) servers by teaching agents more complex workflows that involve external tools and software."

Read that carefully, because it is the whole pattern. The MCP server provides the raw access: it exposes the tools that touch your issue tracker, your cloud console, your data warehouse. The Skill provides the workflow: the sequence, the conventions, the judgment about when to call which tool and what to do with the result.

A concrete shape: an MCP server exposes create_issue, search_issues, and update_issue against your tracker. On its own, the agent can call those, but it does not know your triage rules, your labeling scheme, or your escalation ladder. A Skill named "triage-incoming-bugs" encodes exactly that, and calls the server's tools as its hands. The server is the muscle, the Skill is the training. Neither replaces the other.

So the mature answer to "MCP server or Skill" is often "a thin server for access, and a Skill for the workflow on top." Build the server when there is a real system to reach; build the Skill when there is a real way you want the work done.

One Honest Caveat On the Framework

The clean decision table above is a synthesis, not an Anthropic edict. The primary docs describe the properties of each, and the announcement says Skills "complement" MCP, but Anthropic does not publish a prescriptive "use X here, Y there" checklist. Sharper slogans you may have seen (variations of "MCP is the hammer, Skills explain how to swing it") come from community writers, not the official docs. The framework here is built from the documented properties (state, auth, context cost, distribution), which is the honest way to reason about it. When someone hands you a crisp rule, check whether it is grounded in those properties or just a memorable line.

The Take

Stop treating this as a versus. MCP is a protocol for reaching systems; Skills are packaged expertise for doing work. If your capability is a connection with state and auth, build a server. If it is procedure, judgment, and reference material, build a Skill, and enjoy the near-zero context cost until it fires. And when a capability is both a system and a way of using that system, which is most real engineering work, build a small server for the access and a Skill for the workflow that drives it. The teams that ship reliable agents in 2026 are not the ones that picked the trendier primitive. They are the ones that matched the primitive to the question.

FAQ

What is the difference between an MCP server and an Agent Skill?

An MCP server is a service that exposes capabilities (tools, resources, prompts) to an agent over a standardized JSON-RPC connection, per the MCP spec. It is access to a live system, with state and auth. An Agent Skill is a folder of instructions and optional resources that loads into the agent's context on demand, per Anthropic's docs. It is procedural knowledge about how to do a task, not a connection.

Can Skills and MCP servers work together?

Yes, and Anthropic frames them as complementary. The Agent Skills announcement describes Skills teaching agents "more complex workflows that involve external tools and software." A common pattern is an MCP server that provides access to a system and a Skill that encodes the workflow for using that system's tools.

When should I build an MCP server instead of a Skill?

Build a server when the capability needs a live connection to a running system, holds session state, or requires authentication and per-user scopes. Those are things a static Skill folder cannot provide, since a Skill ships files rather than maintaining a connection.

When is an Agent Skill the better choice?

Choose a Skill when the capability is mostly procedure, judgment, or reference material: house style, release steps, triage rules, or a large lookup document. Progressive disclosure keeps a Skill at roughly 100 tokens until it is triggered, so heavy reference content costs nothing until needed. Skills are also portable across any skills-compatible agent.

Do Skills cost context window space?

Very little until used. Anthropic's docs describe three levels: only name and description (about 100 tokens per Skill) load at startup, the instruction body loads when triggered, and bundled files or scripts load only when read or executed. Script code returns output without the code entering context.

Are Agent Skills specific to Claude?

No. The format "was originally developed by Anthropic, released as an open standard," per agentskills.io, and has been adopted by tools including Cursor, Gemini CLI, GitHub Copilot, OpenAI Codex, Goose, and Letta. Runtime behavior can differ by host: for example, Claude API skills run without network access while Claude Code skills have full network access.

Is MCP changing in 2026?

Yes. The stable spec is dated 2025-11-25, and a release candidate dated 2026-07-28 moves MCP toward a stateless protocol layer. If you are building a server now, build toward that direction; see the stateless migration guide.

Sources

• Model Context Protocol Specification, 2025-11-25
• MCP Basic Transports
• MCP 2025-11-25 Changelog
• MCP 2026-07-28 Release Candidate
• Agent Skills Overview, Anthropic
• Claude Code Skills Documentation
• Agent Skills Open Standard
• Anthropic Engineering: Equipping Agents for the Real World with Agent Skills