What the server would publish

The extension identifier is io.modelcontextprotocol/skills. A server that declares it must implement skills/list and skills/get. It may also implement resources/directory/read. Files still travel through MCP's existing resources/read method. The Agent Skills specification remains responsible for the directory format and the required SKILL.md frontmatter.

A listed skill has frontmatter, a URI, and either a complete file manifest or the marker "dynamic". A normal manifest names every file, its byte size, and its SHA-256 digest. The draft sets baseline limits of 512 resources and 16 MiB per skill.

The list can be empty or partial. That does not prove the server has no other skills. A client that already knows a skill URI can ask skills/get for its entry even when skills/list omitted it.

This lets a host show a catalog of names and descriptions without loading every workflow into the model's context. Full instructions arrive only when selected, and supporting files arrive when needed. That is a practical form of progressive disclosure for a large skill catalog.

The hash has one job

The manifest helps a host detect change. A file that no longer matches its digest must be rejected. A supporting file absent from the manifest is also a verification failure. After fetching SKILL.md, the host must confirm that its frontmatter matches the entry shown before loading.

Those checks can bind approval to a particular set of bytes, but they cannot make the instructions reputable. As the working group's threat model explains, the server supplies both the digest and the content. A malicious server can publish harmful instructions with the correct hash. An intermediary can replace the manifest and file together.

A digest match therefore means "the bytes agree with this manifest," not "someone trustworthy reviewed this." Host interfaces should not dress it up as a safety badge. SEP-2640 does not define signed provenance or a third-party verdict. Such systems could be layered on later, but they are outside the current proposal.

The "dynamic" option draws the boundary more sharply. It is used when stable digests cannot be published. The draft says a dynamic skill offers no content integrity and cannot be tied to content-bound approval. A host may decline to load it. That is a sound policy for release work, regulated processes, or any task that must be reproduced later.

Approval belongs to an origin, not a name

Two servers can publish skill://refunds/SKILL.md, and several skills can share a friendly name such as deploy. The proposed identity is therefore a pair: server identity plus URI. Hosts must keep both in registries, caches, persisted approvals, and any path where files are materialized.

Without that pairing, approval for one deploy workflow could quietly transfer to another source. A remote skill could also shadow a local skill with the same label. This is the same mistake explored in our analysis of untrusted issue text: a familiar label says nothing about authority.

Nested skills need their own consent. Reading a nested SKILL.md as supporting material does not activate it. If a host wants to apply its frontmatter as a separate skill, the user must approve that activation explicitly.

Loading instructions does not grant tools

Skills can contain scripts or ask a model to use shell and file tools. Their frontmatter may include allowed-tools. When that field arrives from a remote server, it is a request for power on the host, not a settled description of policy.

SEP-2640 says fields that widen tool or filesystem access must be ignored unless the user approves the grant for that specific skill. MCP-served content also needs explicit per-skill approval before it can cause host-side code execution. Discovery may be automatic. Permission widening must not be.

The same division matters when an application routes model requests through api.ish.chat. A gateway can centralize model access and provider policy. It cannot decide whether a remote workflow deserves local shell, filesystem, or cross-server capabilities. Only the host next to those capabilities has enough context to enforce that boundary.

Nine checks for an experimental host

Teams testing the draft can start with a concrete policy:

1. Show the originating server beside every remote skill, including in the model-visible registry.
2. Store identity and approval under server identity plus URI. Never use the friendly name alone.
3. Bind consent to the whole digest set. When it changes, show the change and ask again.
4. Read allowed-tools as a permission request. Gate code execution separately.
5. Ask again before activating nested skills or following cross-origin reads.
6. Put verified files in a host-private, immutable cache. Do not replace checked bytes with a later live read.
7. Before writing to disk, reject names that collide after case folding or Unicode normalization on the target filesystem.
8. Add catalog, pagination, and retrieval budgets on top of the per-skill limits.
9. Refuse "dynamic" skills when the job requires reproducibility or content-bound approval.

The division matches our A2A and MCP agent-tool guide: transport, coordination, and authorization remain separate jobs even when one interface exposes all three.

Use remote delivery when it earns the overhead

The working group's guide to choosing remote skills is selective. Server delivery fits instructions tightly coupled to server tools, frequently changing workflows, multi-tenant catalogs, and cross-server orchestration. A static, standalone workflow for one user is usually simpler as local files.

SEP-2640 could make agent know-how easier to find and update. Before any implementation calls that convenient, it should pass a stricter test: a server can advertise a skill without activating it; verified bytes do not gain authority from their hash; loading instructions does not unlock tools; and one approval never leaks to another origin or nested skill. If any of those statements is false, the host has turned a manual into a master key.