MCP vs Skills: where the trust boundary sits
Agent Skills and MCP are complementary, and neither replaces the other. A Skill is a folder of instructions, optionally with scripts, that your agent loads into its own context and executes in its own environment. An MCP server is a separate service your agent connects to over a wire protocol to call tools it does not have. Skills give an agent procedure; MCP gives it reach. The comparison that generic explainers skip, and the one we care about as a registry that scores MCP servers for a living, is where the trust boundary sits: a Skill is code at rest that you can audit once and pin, while an MCP server is a live counterparty that can change behaviour after you have connected to it.
Skills vs MCP at a glance
| Agent Skill | MCP server | |
|---|---|---|
| What it is | A folder with a SKILL.md file (instructions, plus optional scripts and reference files) | A service speaking JSON-RPC over the MCP protocol, exposing tools, resources and prompts |
| Where it runs | Inside your agent’s own execution environment | In someone else’s process: a package you run locally, or a remote endpoint they operate |
| How the agent uses it | Loads the instructions into context, runs bundled scripts itself | Sends tool calls over the wire, receives results back |
| What can change after you adopt it | Nothing, unless you update it or it fetches remote content | Anything: the operator can alter tool schemas and behaviour at any time |
| Trust decision | One-time: audit the files, pin the version | Ongoing: transport, auth, operator and supply chain all stay in scope |
| Credentials involved | Your agent’s own permissions and secrets | Whatever you grant the server, plus its own upstream credentials |
| Best for | Procedure, house style, repeatable workflows, deterministic local scripts | Live data, third-party APIs, shared services, actions in external systems |
What is an Agent Skill?
An Agent Skill is a directory containing a SKILL.md file with YAML frontmatter (a name and a description are the only required fields) followed by free-form instructions. The Agent Skills specification allows optional scripts/, references/ and assets/ directories, so a skill can bundle executable code and documentation alongside its instructions.
Skills load through progressive disclosure. Per the spec, an agent reads only each skill’s name and description at startup (roughly 100 tokens), pulls the full SKILL.md body into context when a task matches (under 5,000 tokens recommended), and touches bundled files only when the instructions call for them. When a skill includes a script, Anthropic’s documentation is explicit that the agent runs it through bash and only the output enters context, never the script’s code.
The format was developed by Anthropic and released as an open standard, and it has been adopted well beyond Claude: the agentskills.io client showcase lists Cursor, GitHub Copilot, Gemini CLI, OpenAI Codex, Goose and dozens of other agents. “Claude Skills” and “Agent Skills” describe the same format; the queries differ, the folder does not.
The detail that matters for the rest of this post: a Skill executes wherever your agent executes. On the Claude API that is a sandboxed container with no network access. In Claude Code, Anthropic’s docs state that skills have the same network access as any other program on your machine. Either way, the code runs with your agent’s permissions, not someone else’s.
What is an MCP server?
MCP (Model Context Protocol) is an open wire protocol. Your agent’s client sends JSON-RPC 2.0 messages to a server, which exposes tools the model can call, resources it can read, and prompts it can use. The current spec revision, 2026-07-28, made the protocol stateless: every request is self-contained and carries its own version and capability information. We cover the protocol itself in our MCP docs.
The structural difference from a Skill is that nothing is loaded into your agent except the tool schema. The implementation stays on the server’s side of the wire. That is precisely what makes MCP useful (the server can hold connection pools, secrets and state your agent should never see) and precisely what makes it a different kind of dependency.
Do Skills replace MCP?
No, and the clearest evidence is that both ecosystems are actively wiring the two together. Anthropic’s own guidance is that “MCP connects Claude to data; Skills teach Claude what to do with that data”, and it recommends using both in the same setup. Meanwhile the MCP project runs a Skills over MCP working group whose draft Skills Extension distributes skills through MCP’s existing Resources primitive. Skills are becoming another artefact an MCP server can serve, which settles the replacement question in practice.
A Skill cannot hold a database connection open, keep an API secret away from the model, or give ten teammates one shared, access-controlled integration. An MCP server cannot cheaply teach your agent your review checklist or house formatting rules; burning a network round-trip and a server deployment on static instructions is the wrong tool. Different problems, different mechanisms.
Where does the trust boundary actually sit?
This is the distinction that feature-list comparisons miss, and it should drive the choice more than anything in the table above.
A Skill’s risk is the risk of code you installed. Everything is on disk before it runs. You can read every file, diff every update, and pin the version in your own repository. Nobody can change it remotely unless the skill itself fetches external content at run time, which is exactly the case Anthropic’s security guidance flags as the highest risk. That guidance is blunt: a malicious skill “can direct Claude to invoke tools or execute code in ways that don’t match the Skill’s stated purpose”, and skills should be treated like installing software. The blast radius of a bad skill is your agent’s entire permission set, on your machine, with your credentials. That is serious, but it is a familiar kind of serious: it is the same trust decision as any dependency you vendor, and you get to make it once, with the full source in front of you.
An MCP server’s risk is the risk of a third-party service. You see a tool schema; you do not see the implementation, and the schema itself is only a claim. The MCP spec’s own security section says descriptions of tool behaviour “should be considered untrusted, unless obtained from a trusted server”. The operator can change what a tool does tomorrow without your agent noticing anything except different results. On top of that sit the layers a Skill simply does not have: a transport that needs TLS, an authentication story, an operator’s infrastructure, and a package supply chain if you run the server locally.
Our registry data shows how much third-party surface that adds up to. As of 29 July 2026, the official MCP registry lists 19,048 servers exposing 20,692 components. 10,895 of those components are packages you would install from npm, PyPI, an OCI registry, NuGet or as an MCPB bundle, each with its own upstream supply chain, and 9,797 are remote endpoints run by someone else. Only 1,201 of those 9,797 remote components require authentication. The median score across the 18,689 servers we have scored is 27 out of 100. Every MCP server you add is a dependency drawn from that pool, and the pool’s baseline hygiene is low.
When should you use a Skill instead of MCP?
Reach for a Skill when the capability is knowledge or procedure rather than access:
- Workflow and house style. Review checklists, formatting rules, “how we write migrations here”. This is the core use case.
- Deterministic local operations. A tested script beats having the model improvise the same code every session, and its source never costs context.
- Anything you want to audit once and pin. Skills live in version control next to your code; updates arrive as diffs you review.
- Per-project context. Skills scope naturally to a repository or a team without standing up any infrastructure.
When do you need an MCP server?
Reach for MCP when the capability is access to something outside the agent:
- Live data. Databases, ticket queues, observability platforms, anything that changes between requests.
- Third-party APIs with credentials. The server holds the secret; the model only sees tool results.
- Shared, governed integrations. One remote server with proper authorisation serves a whole organisation with central control. If you maintain one, our guide to adding OAuth to a remote server covers the current spec’s requirements.
- Actions with side effects in external systems. Sending, writing, deploying: things that belong behind a service boundary and an audit log rather than inside an agent’s sandbox.
Using both together is the normal end state, and increasingly the designed one: instructions as Skills, access through MCP, and (once the Skills Extension lands) skills themselves discovered via MCP.
How do you vet each before you adopt it?
For a Skill: read all of it. SKILL.md, every script, every reference file. Look for network calls the description does not explain, file access outside the task’s scope, and instructions that fetch external URLs at run time. Prefer skills from sources you already trust, and pin what you install.
For an MCP server: you cannot read the implementation, so you have to assess the operator and the surface instead. Does the transport use TLS? Does a remote endpoint require authentication at all (most in the registry do not)? Is the package’s supply chain clean? Has the tool schema changed recently? This is the assessment our scoring engine automates: we connect to every server in the official registry, read its tool schemas, probe transport and auth, and check package supply-chain signals. Scores are independent estimates rather than guarantees, and signals we cannot verify are marked inconclusive rather than guessed, but they turn “some stranger’s server” into a measurable dependency.
Before you wire a new MCP server into an agent, look it up on the VerifyMCP registry and read its score breakdown, then skim the MCP threat model so you know which failure modes the score is measuring. Ten minutes of reading is cheap compared with discovering the trust boundary the hard way.