SKILL.md Beat MCP (Barely): Skills, Trust Tiers, and the Agent Skills Supply Chain

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 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.

Skills are a supply chain

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 rather than the scripts alone. 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.

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, so 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.

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. It has no signature, no hash, no declared permissions beyond the experimental tool list, and 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

Skills are cheap to load because of progressive disclosure, and 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 pipeline rather than a single scanner, with each stage catching 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.

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.

Package ecosystems learned all of this over twenty years; here it is applied to a package format that happens to be prose.

What to require from a registry

When you evaluate a registry, ask for five things.

Provenance, meaning who published this, under which identity, and whether that identity can 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 cheap options are also the ones with the fewest boundaries, which is why the order runs this way. 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

Give skills the boundary they lack

Skills ship in 9 of the harnesses studied and MCP in 8 of them. The mechanism that won on adoption is the one with no boundary of its own, and ClawHavoc put 1,184 malicious skills into one marketplace that had vetting. Pin skills by content hash, give each one a tier that the harness and the proxy enforce, and run every tool call a skill triggers through the same policy as an MCP tool call.