What are Agent Skills, and how are they different from MCP servers?

The shortest distinction

A Skill is a file format. An MCP server is a running process. That single sentence resolves most of the confusion, because the two are usually described in the same breath as if they were rival standards.

The Agent Skills specification defines a skill as a directory containing at minimum a SKILL.md file, which holds YAML frontmatter followed by Markdown content. Optional subdirectories can carry executable scripts, reference documentation, and template assets. Nothing runs continuously; the folder simply sits on disk until the agent decides to read it.

The Model Context Protocol documentation describes MCP as an open protocol supported across a range of clients and servers, listing assistants such as Claude and ChatGPT and development tools such as Visual Studio Code and Cursor. An MCP server is something you start, and it stays available to answer tool calls and serve data while the agent works.

How a Skill actually loads

The mechanism worth understanding is progressive disclosure, because it explains why installing many skills does not wreck an agent's context window. The Claude Platform documentation breaks it into three levels and publishes the token cost of each.

At level one, only the YAML frontmatter is loaded, and the documentation puts this at roughly 100 tokens per Skill, held in the system prompt from startup. At level two, when a request matches the description, the agent reads the SKILL.md body, which the documentation expects to stay under 5,000 tokens. At level three, bundled files cost nothing until they are actually opened, and bundled scripts are executed through bash so that only their output enters the context window, never their source.

• Level 1, metadata: always loaded, roughly 100 tokens per Skill, name and description only.
• Level 2, instructions: loaded when the Skill is triggered, expected to stay under 5,000 tokens.
• Level 3, resources: zero cost until read; referenced files load on access.
• Bundled scripts: run through bash, and only the output consumes context.

What goes in a SKILL.md file

The specification is small enough to read in one sitting, which is a large part of the appeal. Two frontmatter fields are required and the rest are optional.

The name field is capped at 64 characters and must use lowercase letters, numbers, and hyphens without a leading or trailing hyphen. The description field is capped at 1,024 characters and must be non-empty. Because the description is what the agent matches your request against, the documentation is explicit that it should state both what the Skill does and when to use it. A vague description is the most common reason a Skill never triggers.

• name: required, maximum 64 characters, lowercase letters, numbers and hyphens.
• description: required, maximum 1,024 characters, states what it does and when to use it.
• license, compatibility and metadata: optional, with compatibility capped at 500 characters.
• allowed-tools: optional space-separated list of pre-approved tools, and the specification marks it experimental.

When to reach for which

The practical test is whether the agent lacks access or lacks procedure. If the agent cannot reach the system at all, no amount of written instruction fixes that, and you need an MCP server or an equivalent connector. If the agent can already reach everything but keeps doing the work in a different way each time, a Skill is the cheaper and more portable fix.

The two also compose. A Skill can describe your organization's review procedure in detail while an MCP server supplies the live ticket data that procedure operates on. Treating them as alternatives is what leads teams to build a server for something that was only ever a documentation problem.

• Choose a Skill when the knowledge is procedural, repeatable, and versionable as text.
• Choose an MCP server when the agent needs a live connection, authentication, or data it cannot otherwise reach.
• Choose both when a documented procedure has to operate on a live system.
• Choose neither when a single well-written prompt already produces the result reliably.

The security tradeoff to take seriously

This is a real, inherent risk rather than generic caution about new tooling. The documented architecture has skills running in an environment where the agent has filesystem access and can execute bash commands, and bundled scripts are executed rather than merely read. Installing a third-party skill therefore means accepting code that may run on your behalf.

The mitigations are ordinary and effective. Read the SKILL.md and every file under a scripts directory before installing, exactly as you would review any dependency. Prefer skills published in an inspectable public repository over an opaque bundle. The Anthropic reference repository and the Trail of Bits security-skill collection are both public and readable for this reason. Treat the allowed-tools field as a hint rather than a boundary, because the specification labels it experimental. And apply the same caution to any skill whose instructions tell the agent to fetch remote content, since that content becomes instructions the agent has read.

Limits of this answer

RepoRadar has not benchmarked skill-triggering accuracy across agents, and no such measurement is implied here. The token figures quoted above are the values published in the vendor documentation, not independently measured results.

Support also varies by product and changes over time. The specification is published as an open format with cross-product reuse as a stated goal, but whether a given agent honours every optional field is a question to settle against that product's own current documentation rather than against this page.

A useful next action

Take one procedure you have explained to an agent more than twice, and write it as a folder with a single SKILL.md file. Put the workflow in the body and spend most of your effort on the description field, because that string decides whether the Skill is ever loaded. Run it against a task you have done manually and compare the result.

If that experiment shows the agent still cannot reach a system it needs, that is your signal to add an MCP server, and RepoRadar's answer on what an MCP server does covers that decision in more depth.