Skills over MCP is final: what 3 methods and per-file digests change for your agents

Your MCP server hands an agent its tools. Until now it had no standard way to hand over the instructions for using those tools: the workflow, the order of operations, the things you should never do. The Skills extension (SEP-2640) closed that gap. The proposal was marked Final when PR #2640 merged on September 13, the spec is written against base protocol revision 2026-07-28, and the work now lives in modelcontextprotocol/ext-skills with a proper documentation site instead of a repo full of design notes.

I read the specification end to end because this is the seam where my own tooling lives: config files that teach agents how to work. Here is what matters in it.

What actually shipped

The extension id is io.modelcontextprotocol/skills. It adds exactly three methods on top of what MCP already has:

• skills/list enumerates the skills a server serves, returning each skill's frontmatter verbatim plus a manifest of every file with a digest.
• skills/get returns the entry for one skill by URI.
• resources/directory/read (optional) lists the children of a directory, so an agent told to "use the template in templates/" can actually look inside.

Every file in a skill is an ordinary resource, conventionally under the skill:// scheme, and is read with the standard resources/read method. No new transport, no new payload format. A skills/list call looks like this:

{
  "method": "skills/list",
  "params": {}
}

And an entry in the result carries the manifest:

{
  "uri": "skill://git-workflow/SKILL.md",
  "resources": [
    {
      "uri": "skill://git-workflow/SKILL.md",
      "digest": "sha256:b95a384300adeea2d902f7d19cd7c04b378ef58e09759107b9c7db4dcacbaa25",
      "size": 1428
    }
  ]
}

The name in the frontmatter must equal the final segment of the URI path, so the skill name is recoverable from the URI alone, without reading anything.

The design decision that matters most

The extension does not redefine what a skill is. The spec says outright that it defines only the transport binding, and that the payload format belongs to agentskills.io. One source of truth for the format, and MCP is one way to deliver it.

That is the right split. Skills already exist as a directory with a SKILL.md at the root, YAML frontmatter with a name and description, and references/, scripts/, and examples alongside. If you have skills in a GitHub repo today, they are already valid payloads. You are not migrating anything, you are exposing what exists.

Per-file digests, not per-skill

The manifest carries a sha256 digest and a byte size for every file, not just the SKILL.md. The rationale documents why: an earlier draft digested only SKILL.md, which meant a server could get a benign skill approved and then swap out a reference file the model reads just as faithfully. Every file is bound now, so a changed or added file shows up as a verification failure. A read whose byte length differs from the manifest's size is a verification failure too, even before anyone computes a digest.

Honest limit, straight from the spec's security considerations: the digests are unsigned and supplied by the same server that supplies the content. A match proves the two are consistent, not that either is trustworthy. Any intermediary on the path, such as a gateway, can rewrite both together. This is tamper-evidence against drift, not against a malicious server.

The adoption number everyone will quote

Kin Lane measured adoption the day after the working group call: he probed 1,432 hosted MCP endpoints from his API catalog, 572 completed the handshake (699 wanted credentials he did not have), and exactly two declare the extension: Hugging Face, and a French building-trades marketplace called RenooLab that shipped it the week the SEP went final.

Two out of 572 sounds like a failure until you notice the other number in the same piece: of the 679 API providers in his catalog that publish skills they wrote themselves (2,568 skills in total), 270 also run a hosted MCP server, publishing 843 skills. Those 270 companies already operate both halves of this extension, the server and the instructions for using it, in two different places. An agent connected to their MCP server cannot learn those skills exist unless someone wires it up by hand. The spec has been final for nine days. The design is done; the serving is what is missing.

What this means for your setup

If you run an MCP server and your skills live in a repo or a docs page, you are one of the 270. The migration path is short: your SKILL.md files already exist, the extension asks you to expose them as resources and answer two methods. Once you do, you get digests your users can pin, and an agent that finds your tools also finds how to use them.

There is also a context economics angle. Skills load through progressive disclosure: the name and description ride in the system prompt, the body loads when a task matches, and bundled files load only when needed. That is the same budget discipline I keep hitting when measuring what 9 MCP servers cost in tokens before the first prompt. Serving instructions over MCP does not change that model, it just gives the instructions a standard address. If you maintain a repo of agent config files (I keep a validator-tested starter kit for exactly this), the same files can become server-served skills without edits to their content.

Two traps in the spec worth knowing

First, a skills/list result may legitimately be empty or partial. A documentation server that turns each endpoint into a skill might have thousands, and a gateway fronting an external index cannot enumerate at all. The spec is explicit that hosts must not treat an empty listing as proof there are no skills, and must support loading a skill given only its URI. If you build a client, that sentence is the difference between working with gateways and silently missing every skill behind one.

Second, the SDKs are not done. The official Go, TypeScript, Python, and C# SDKs all have open pull requests for the extension; Go passes the conformance suite, the others are in flight. Host adoption is the real gate: until editors and agent harnesses read the listing, serving skills is a tree falling in an empty forest. MCP Inspector has partial support as of 2.6.0. I would watch the client matrix, not the spec repo, for the signal that this is real.

The takeaway

Instructions and tools have lived in different places since both existed: tools in a server, instructions in a README nobody reads at the right moment. SEP-2640 makes serving them together a protocol behavior instead of a convention, with content binding that catches drift. The spec is final, the servers are barely starting, and the 270 companies already running both halves in two places are the ones with the least work left to do.