The eleven-system harness study has one number that surprised people who assumed MCP had already won the extension war. Skills, the Markdown-plus-scripts packages that a harness loads as a procedure, ship in nine of the eleven systems. MCP ships in eight.
One system is not a landslide. But the direction matters, and the reasons behind it matter more, because they tell you what each mechanism is actually for. And because the second half of this story, the security of the skill supply chain, is where the real risk is right now.
TL;DR
- A skill is a packaged procedure: a SKILL.md the model reads at runtime, plus optional scripts, configuration and tool bindings. An MCP server is a protocol boundary that exposes tools, resources and prompts over JSON-RPC.
- Skills won on adoption because they are cheap to write, cheap to load, and live next to the code. MCP won where the boundary is real: shared services, audit, revocation, and cross-organisation access.
- Skill registries and trust tiers are appearing because the skill supply chain is already being attacked: one campaign put more than a thousand malicious skills into a marketplace that had vetting.
- Treat skills like dependencies with a pinned version and a trust tier, run them inside the same policy proxy as MCP tools, and vet the natural-language part, not only the scripts.
What a skill actually is
The word gets used loosely, so here is the shape the harnesses converged on.
A skill is a directory. At its centre is a SKILL.md file: instructions the agent reads at runtime that teach it how to use specific tools, run shell commands or talk to an API. Around it may sit scripts the instructions reference, configuration, examples, and a manifest that declares what the skill needs. The harness discovers skills from known locations, loads the ones relevant to the task, and the model follows them the way it would follow any other context.
That is the whole mechanism. There is no protocol. There is no server. The skill is context plus procedure, and the model does the rest.
An MCP server is a different animal. It is a process that speaks JSON-RPC and exposes named tools with schemas, resources with URIs and prompts with arguments. The harness calls it over a transport. There is a boundary, and the boundary is the point: the server can run somewhere else, under a different identity, with its own audit log and its own policy.
Why skills won on adoption
Skill or MCP server? Score by what the integration needs
| Option | Cheap to write and change(w:1) | Cheap to load into context(w:1) | Needs a trust or process boundary(w:1) | Shared across teams or organisations(w:1) | Needs audit and revocation(w:1) | Weighted score |
|---|---|---|---|---|---|---|
| Skill (SKILL.md plus scripts) | 5 | 5 | 1 | 2 | 2 | 60% Lives with the code. Loaded on demand. Trust is whatever the harness gives the model. |
| MCP server | 3 | 3 | 5 | 5 | 5 | 84% A real boundary with a real cost. Right when the thing behind it is shared, sensitive or someone else's. |
| Direct function or CLI | 4 | 5 | 2 | 1 | 2 | 56% The default when nothing needs sharing. The harness study found bash-capable models often prefer it. |
Three things explain the adoption gap.
Skills are cheaper to make. A SKILL.md is a Markdown file. A team can write one in an afternoon, check it in next to the code it describes, and change it in a pull request. An MCP server is a process with a schema, a transport and a deployment. Both are fine; one is an order of magnitude less ceremony.
Skills are cheaper to load. The harness study documents deferred tool loading and capability-gated snippets as recurring patterns: harnesses learned to keep tool catalogs out of the context until needed. A skill is discovered and loaded on demand. An MCP server's tools/list used to be pulled every turn, which is exactly what the 2026-07-28 revision fixed with cacheable lists.
Skills match how the model works. A model following a procedure written in prose, with commands it can run, is doing the thing it is best at. The harness study's line about the field running on hand-rolled loops and deterministic retrieval applies here too: the simplest mechanism that works tends to win inside a harness.
MCP kept its eight because of the things skills cannot do. When the thing being exposed is a shared service, when access has to be revocable by someone other than the developer, when the caller is an agent in another organisation, the boundary is the feature. The Hacker News thread on the empirical harness study put it bluntly: some commenters argued bash makes tool frameworks redundant, others answered that MCP solves audit and revoke, which is a different problem from raw performance. Both are right about their own case.
The part nobody budgeted for: skills are a supply chain
Here is the uncomfortable symmetry. A skill is instructions the model follows. A prompt injection is instructions the model follows. The only difference is who wrote them and whether you meant to load them.
The 2026 research on skill security is not theoretical. SkillVetBench, a two-stage vetting benchmark for open skill ecosystems, exists because static scanners miss most skill threats: the malicious behaviour is often expressed outside conventional executable code, in the natural-language instructions, and has no code-level signature. PhantomSkill and MalSkills document code injection and neuro-symbolic detection for the same reason. And the ClawHavoc campaign introduced 1,184 malicious skills into the ClawHub marketplace despite official submission vetting.
The attack surface is the whole artifact, not the scripts. A skill can steal credentials, exfiltrate data or deliver malware through its instructions, its installation commands, its auxiliary scripts, its configuration, its memory interactions, or a chain of individually harmless operations.
A benign-looking skill that reads your secrets
Actor: A contributor publishing to a public skill registry, or an attacker who compromised a popular skill's maintainer
Asset: Credentials and data reachable by the harness: environment variables, cloud tokens, source, customer records
Entry point: A SKILL.md that is installed because its name and description match a common task
Impact: Credential theft and data exfiltration that survives the session through memory, from a skill that passed a code scanner
- The skill's instructions tell the model to 'verify the environment' by printing configuration, which includes secrets.
- A helper script referenced by the instructions posts the output to a 'telemetry' endpoint.
- The skill asks the model to remember the endpoint for future runs, so memory carries the exfiltration path forward.
- None of the three steps looks malicious in isolation, and no step contains a known malware signature.
- - Trust tiers: community skills run with no network egress and no access to secrets unless a human promotes them.
- - Pin skills by content hash, not by name; review the diff on every update the way you review a dependency bump.
- - Semantic vetting of SKILL.md, not only script scanning; treat the prose as code under review.
- - Run skill-driven tool calls through the same policy proxy as MCP tools: allow, deny or ask, with redaction and an audit log.
- - Memory writes initiated by a skill require review or are scoped to the skill's own namespace with an expiry.
- - A canary secret in the environment; any egress of it fails the test.
- - A recorded run of each installed skill with the network mocked; unexpected destinations fail the test.
- - A diff check in CI that blocks skill updates whose SKILL.md changed without a review.
Trust tiers: the registry pattern that is emerging
Registries with trust tiers are the response the ecosystem is converging on, and the harness study notes the first agent-authored skills appearing in them, which raises the stakes further: soon a meaningful share of skills will have been written by agents for agents.
A workable tier model has three levels. It is not standardised yet, so treat these as the shape rather than the names.
Tier 0, first party. Skills your team wrote, reviewed and pinned. They may reach what the task needs, still through the policy proxy.
Tier 1, vetted. Skills from a registry that passed semantic and script vetting and are pinned by hash. They may reach the filesystem and approved services, with no direct access to secrets and with egress allow-listed.
Tier 2, community. Anything else. Read-only tools, no network, no secrets, no memory writes. Useful for procedures, useless for exfiltration. Promotion to tier 1 is a human decision with a review, never an automatic one.
The tier is enforced by the harness and the proxy, not by the skill. A skill cannot grant itself privileges the host does not provide, which is the same rule the MCP roadmap applies to protocol extensions.
A SKILL.md, line by line
The format is specified, and the specification is short enough to hold in your head. A skill is a directory whose name matches the skill's name, containing a SKILL.md and, optionally, scripts/, references/ and assets/. The SKILL.md has YAML frontmatter followed by a Markdown body with no format restrictions.
---
name: deploy-checklist
description: Runs the pre-deploy checks for the billing service and reports which gate failed. Use before any production deploy of billing, or when the user mentions deploying, releasing or shipping billing.
license: Apache-2.0
compatibility: Requires git, docker and access to the internal registry
metadata:
author: platform-team
version: "1.4"
allowed-tools: Bash(git:*) Bash(docker:*) Read
---
# Deploy checklist
1. Run `scripts/preflight.sh` and read its JSON output.
2. If any gate is `failed`, stop and report the gate name and its message.
3. If all gates pass, run `scripts/deploy.sh --dry-run` and show the plan.
See [references/GATES.md](references/GATES.md) for what each gate checks.Two fields are required. name is at most 64 characters of lowercase letters, digits and single hyphens, and must match the directory name. description is at most 1,024 characters and should say both what the skill does and when to use it, with the keywords an agent would match against a task. The remaining fields are optional: license, compatibility (up to 500 characters of environment requirements), a free metadata map of string keys to string values, and allowed-tools, an experimental space-separated list of pre-approved tools such as Bash(git:*).
The body is instructions. The spec recommends step-by-step instructions, examples of inputs and outputs, and common edge cases, and asks you to keep the file under 500 lines with detailed material moved into references/. There is a reference validator, skills-ref validate ./my-skill, that checks the frontmatter and naming rules.
That is the entire mechanism. Now look at what is not in it: no signature, no hash, no declared permissions beyond the experimental tool list, no boundary between the skill's text and the model's instructions. Everything the supply-chain research worries about follows from that absence.
Progressive disclosure is the feature and the attack surface
The reason skills are cheap to load is progressive disclosure, and it is worth understanding precisely because the vetting has to follow the same path.
At startup an agent loads only the name and description of every installed skill, about a hundred tokens each. When a task matches a description, the agent loads the full SKILL.md body, which the spec recommends keeping under five thousand tokens. Files under scripts/, references/ and assets/ are loaded only when the instructions send the agent to them, one level deep from the skill root.
Three consequences for security.
The description is the trigger. A malicious skill wants to be activated, so its description will be written to match common tasks broadly. A skill whose description promises to help with "deploys, releases, shipping, publishing, CI, builds" is either very useful or fishing. Vet descriptions as carefully as bodies.
The dangerous instructions can live in references/. A reviewer who reads SKILL.md and stops has not read the skill. The body can say "see references/SETUP.md before continuing", and that file can say anything. The SkillVetBench finding that malicious behaviour is often expressed outside conventional executable code applies to Markdown under references/ as much as to the main file.
Scripts are the part static scanners see, and the part attackers can avoid. A skill can exfiltrate without a single script by instructing the model to run a shell command with its own tools. The instruction is prose; it has no code-level signature; and if the harness allows the tool, the harness will run it.
A vetting pipeline in four stages
The research points at a shape, and it is not a scanner. It is a pipeline where each stage catches what the previous one cannot.
Stage one, semantic review of every Markdown file. Read SKILL.md, everything under references/, and any other prose in the directory as if it were code under review, because for the model it is. The questions: does any instruction reach outside the task the description promises? Does any step touch credentials, environment variables, the network, or memory? Does any instruction try to change how the agent treats later instructions? SkillVetBench frames its first stage as exactly this, semantic vetting over the natural-language specification, and it is the stage most teams skip.
Stage two, static analysis of scripts and manifests. Conventional scanning of scripts/ and any configuration: known-bad patterns, encoded payloads, network calls, credential reads. Necessary, and the least sufficient stage, because it only sees code.
Stage three, a recorded run in a sandbox with a canary. Install the skill in a harness whose environment contains a canary secret and whose network is mocked to record every destination. Run it against its own examples and against a task its description would match. Anything that reads the canary, contacts an unexpected destination, or writes to memory fails. The recording is the evidence, and it is reusable: replay it in CI whenever the skill or the harness changes.
Stage four, pin and record. Hash the whole directory, not just SKILL.md. Store the hash, the trust tier, the reviewer, the date and the recording. An update to any file in the directory is a new hash and goes back to stage one. This is the step that turns a skill from a folder someone downloaded into a dependency with a provenance.
None of this is exotic. It is what package ecosystems learned to do over twenty years, applied to a package format that happens to be prose.
What to require from a registry
Registries with trust tiers are appearing, and the harness study notes the first agent-authored skills in them, which means the volume of skills that no human wrote is about to grow. When you evaluate a registry, ask for five things.
Provenance: who published this, under which identity, and can that identity be revoked. Content hashes for every version, so a pin means something. A published trust tier with the vetting each tier received, so "vetted" is a claim you can audit rather than a badge. Revocation that reaches installed copies, because ClawHavoc put 1,184 malicious skills into a marketplace that had vetting, and the question after an incident is how fast the bad copies stop running. And a clear label on agent-authored skills, which should start at the lowest tier no matter who the agent belonged to.
A registry without those is a download site. That is fine for browsing and not fine as a source for anything that runs with write access.
Skill, MCP server, or a plain function: the decision in order
The adoption numbers say teams reach for skills first and MCP second. Here is the order of questions that gets you to the right one without the hindsight.
First, does this integration need to be shared across trust boundaries: with another team, another organisation, or a service whose owner is not you? If yes, it needs a boundary, and the boundary is an MCP server. Audit, revocation and identity live there, which is what the MCP defenders in the Hacker News thread meant.
If not, is it a procedure the model should follow or a capability the model should call? Procedures, "how we deploy", "how we triage", "how we write a migration", are skills. They are prose with examples and a few scripts, they load on demand, and they live next to the code they describe.
If it is a capability, does the harness's own action space already cover it? The empirical harness study found that bash-capable models do well with a bash-only interface at lower cost, and the source-code study found production harnesses retrieve with ripgrep and tree-sitter rather than with anything more elaborate. If the model can do it with a shell command, wrapping it in a tool adds ceremony and a schema to maintain.
Only then, if it is a capability the shell cannot express safely, a local function or tool with a tight schema. And even then, run it through the same policy proxy as everything else.
The order matters because the cheap options are also the ones with the fewest boundaries. Choosing them is right most of the time. Choosing them without the trust tier and the proxy is how the supply-chain numbers happen.
The checklist for shipping skills
Before a skill runs in a harness that can reach anything real
0/8Where this leaves skills and MCP
Both are staying. Skills are the right mechanism for procedures that live with the code and cost nothing to load. MCP is the right mechanism when there is a boundary worth paying for. The number that should worry you is not 9 versus 8; it is 1,184 malicious skills in one marketplace with vetting, against a mechanism that has no boundary of its own.
Give skills the boundary they lack. Pin them, tier them, and run them through the proxy. Then the adoption numbers can keep climbing without the incident count following.