MCP vs Agent Skills: what each does and how to use them together
On this page
An MCP server gives an agent new tools: functions it can call to read or change something in another system. An Agent Skill gives an agent knowledge of how to do a task: a folder with a SKILL.md file of instructions, plus optional scripts and reference files, loaded only when the task calls for it. They answer different questions ("what can the agent reach?" versus "how should it go about this?"), so the useful comparison is about where each fits and how they combine.
Current as of October 2026 and MCP specification revision 2026-07-28.
What an Agent Skill is
A skill is a folder. The only required file is SKILL.md, whose frontmatter must have a name (up to 64 lowercase letters, digits and hyphens, matching the folder name) and a description of up to 1,024 characters that says what the skill does and when to use it. The Agent Skills specification also defines optional license, compatibility, metadata and an experimental allowed-tools field. The format was originally developed by Anthropic and released as an open standard.
release-notes/
├── SKILL.md
├── references/
│ └── style.md
└── scripts/
└── changelog.py---
name: release-notes
description: Drafts release notes from merged pull requests in our house style. Use when the user asks for release notes, a changelog or a summary of what shipped.
---
# Release notes
1. Run `python scripts/changelog.py --since <last-tag>` to list merged PRs.
2. Group entries by the labels in references/style.md.
3. Write one line per change, user-facing wording only, no PR numbers.In Claude Code, project skills go in .claude/skills/<name>/SKILL.md and personal ones in ~/.claude/skills/, and you can run one directly with /release-notes as well as letting Claude pick it up. Claude Code's skills docs list extra frontmatter it understands, such as disable-model-invocation: true for skills that should only run when you type the command.
How a skill reaches the model depends on the client. The integration guide describes three routes: the model reads SKILL.md with its own file tool, the client offers a dedicated activation tool, or the client injects the content into the prompt. Bundled scripts are different. They only help if the agent has somewhere to run them.
Progressive disclosure
Skills are built so that installing many of them costs little. Both the specification and Anthropic's Agent Skills docs describe three levels:
| Level | When it loads | Approximate cost |
|---|---|---|
Metadata (name, description) | At startup, for every skill | About 100 tokens per skill |
SKILL.md body | When the task matches the description | Under 5,000 tokens recommended |
| Referenced files and scripts | Only when the instructions point to them | Nothing until read; in Claude's environment, a script's code never enters context, only its output |
When Claude runs scripts/changelog.py, only what the script prints reaches the model, so a skill can bundle a large reference file or a long script without paying for it until it's needed.
MCP started from the opposite end: the client lists every tool with its full schema. Clients have since added their own deferral. Claude Code's tool search, on by default, loads only tool names and server instructions at session start and fetches full definitions on demand; its docs say server instructions help Claude know when to search for your tools, "similar to how skills work". Clients that load all discovered tool definitions into the model's context pay that cost up front.
What an MCP server is
An MCP server exposes capabilities over a protocol. Its tools each have a name, a description and a JSON Schema inputSchema, per the tools specification, and the client calls them with tools/call. A remote server runs elsewhere and is reached over HTTPS:
claude mcp add --transport http linear https://mcp.linear.app/mcpThe server holds the code and its connection to the upstream system. The agent never sees how a tool like search_issues is implemented; it sees a schema and a result. That's the right shape for anything that touches another system's data with its own authentication: issue trackers, CRMs, databases, monitoring.
Side by side
| Agent Skill | MCP server | |
|---|---|---|
| What it adds | Procedures, conventions, domain knowledge, helper scripts | Callable capabilities in other systems |
| Where it runs | Inside the agent's own environment | Its own process: locally over stdio or remotely over Streamable HTTP |
| How the agent finds it | Name and description loaded at startup; body loaded when relevant | tools/list returns names, descriptions and input schemas |
| Context cost before use | About 100 tokens per skill | Tool definitions, unless the client defers them |
| Credentials | None of its own; uses whatever the agent's environment has | Its own, though where they live varies: a server-side upstream credential, or a token the client supplies |
| Execution environment | Client-dependent; bundled scripts require an execution environment | Not needed in the client for remote servers |
| Portability | Any client that supports the format | Compatible MCP clients, where transport, protocol version and authentication match |
Knowledge vs access
A useful test: if you deleted the skill, could the agent still do the task with enough prompting? Usually yes, with less consistency. Removing an MCP server removes that integration; the agent may still reach the service through a CLI, an API or another tool, but not through that interface.
Skills suit:
- House style, review checklists, naming conventions and runbooks.
- Multi-step procedures with a fixed order, like a migration that must back up first.
- Deterministic helpers a script does better than generated code, such as validating a file format.
- Domain context: which tables hold revenue data, which labels mean what.
MCP servers suit:
- Exposing a system through a standard tool interface.
- Agents with no shell or file system, such as claude.ai connectors and hosted agents.
- Access that needs its own credential, scopes and audit trail.
- Capabilities several compatible apps should share.
A skill that teaches MCP tools
The two compose well. An MCP server provides create_issue; a skill tells the agent how your team files issues. Anthropic's skill authoring best practices cover this case: refer to MCP tools by fully qualified name, in the form ServerName:tool_name, so the agent doesn't fail to find the tool when several servers are connected.
---
name: filing-bugs
description: Files bug reports in our tracker with the required fields and labels. Use when the user asks to file, log or report a bug.
---
# Filing bugs
1. Search first with the Linear:search_issues tool. If a match exists, add a comment instead.
2. Create the issue with Linear:create_issue in the team from references/teams.md.
3. Always set priority and one area label. Put reproduction steps in a numbered list.
4. Never assign the issue to someone; triage assigns.The tool names here are placeholders; use the ones your client lists for the server. The skill carries the process and the server carries the access. Changing the process means editing Markdown, with no server deploy.
A skill's instructions are guidance, not enforcement. "Never assign the issue" shapes what the model tries. It doesn't stop a call to update_issue with an assignee. Enforcement belongs in permissions.
Security differences
Skills run with the agent's permissions. Anthropic's documentation says to use skills only from trusted sources, because a malicious skill "can direct Claude to call tools or run code in ways that don't match the Skill's stated purpose". It recommends auditing every bundled file, and warns that skills which fetch external URLs can pull in malicious instructions even if the skill itself was clean. Where a skill runs matters too: on the Claude API, skills run in a container with no network access, while in Claude Code they have the same network access as any program on your computer. The integration guide also suggests clients gate project-level skills on a trust check, since a freshly cloned repository could carry one.
allowed-tools widens, it doesn't narrow. In Claude Code, a skill's allowed-tools pre-approves the listed tools during the turn that invokes it. The docs say it "does not restrict which tools are available": everything else stays callable under your normal permission settings. A skill with allowed-tools: Bash(git push *) can push without asking.
MCP servers have their own trust boundary. A server decides what each tool does and may hold a credential. The risks differ: a poisoned tool description, an over-scoped token, a server whose tools change after you approved them. The tools specification says clients must treat tool annotations as untrusted unless they come from trusted servers. MCP security risks covers those attacks.
Credentials sit in different places. A skill has no credential of its own. If its script calls an API, it uses a token the agent's environment already holds, which may be broader than the task needs. A remote MCP server can keep its upstream credential outside the agent's environment. The client still holds its MCP credential, and some servers accept a provider token directly, so check how a given server is set up.
Picking one, or both
- You repeat the same instructions in every chat: write a skill.
- The agent needs a system it has no interface to: connect an MCP server.
- The agent can reach a system but uses it inconsistently: add a skill that teaches the server's tools.
- A procedure must run the same way each time: a skill with a script, where the client can run scripts.
- The agent has no shell: instruction-only skills can still work if the host loads them; script-based skills need an appropriate runtime. Remote MCP servers need neither.
- Several apps and people need the same access with different limits: MCP, behind shared permissions.
Permissions for skills and servers
Skills and servers are controlled in different places. In Claude Code, Skill(name) permission rules decide which skills Claude may invoke, and the ordinary rules for Bash, file edits and MCP tools govern what a skill's steps can actually run. Review a skill's allowed-tools line before installing it, since that is where it can loosen those rules for a turn.
MCP tools get their own allow, ask and deny rules in each client, compared in the MCP allowlist guide, or rules at a gateway shared by every app. Toolstile is one such gateway, for remote MCP servers only. What an MCP gateway is explains the approach and permissions lists the per-tool rules.