Independent developer guide. Not affiliated with HarnessRouter or the official UHP project.

Skills Over MCP: SEP-2640 and the implementation lifecycle

Skills Over MCP lets a server publish agent instructions and supporting files through MCP. The extension defines discovery and retrieval; Agent Skills defines the files, and the consuming host decides whether to trust and act on them.

Page reviewed 4 Oct 2026 Source and review policy

Current guidance and dated source history

Choose an integrity path for the selected skill

The released Skills specification distinguishes a complete resource manifest from resources: "dynamic". That distinction changes what a host can promise before it follows the instruction. The extension remains io.modelcontextprotocol/skills, based on MCP 2026-07-28; UHP 2026-09-28 Draft governs the separate harness execution boundary. Both sources were reopened on 4 October 2026.

Selected entry	Host handling	Approval consequence
Resource array with digests	Hold the entry; verify each read’s raw byte length and SHA-256 digest	An approval bound to those bytes cannot silently cover a changed manifest
`resources: "dynamic"`	Treat content as unverifiable by digest; still compare `SKILL.md` frontmatter with the held entry	Do not describe a cache hit as immutable-content verification
Directory listing returned	Use it for discovery within its advertised scope	Do not append unlisted files to a held immutable manifest
Entry changes during retrieval	Refresh deliberately and reconsider the acting window	Do not mix old instructions with newly discovered supporting files

A useful failure fixture changes a helper file after skills/get but before resources/read. The host should either reject inconsistent bytes or establish a new selected entry and its trust decision. Keep the server origin and resource URI with the entry: two skills named review from different origins are not interchangeable. Instruction-state provenance explains why the instruction actually applied to an action matters beyond discovery. This is host design guidance; no SDK/client support is inferred from the specification’s publication.

Implement the transport, not a new package format

The current stable Skills extension specification targets MCP 2026-07-28 or later and identifies itself as io.modelcontextprotocol/skills. It specifies skills/list, skills/get and ordinary resources/read, plus optional resources/directory/read. A successful SEP or published specification does not establish that your particular client supports these methods.

SEP-2640’s Final/merged history is preserved below. For implementation, use the stable extension source reviewed on 4 October 2026, rather than assuming the proposal’s earlier shape is the whole current contract.

A minimal retrieval lifecycle

This is a conceptual method sequence, not a complete wire transcript. Actual requests must include the base protocol’s required request metadata.

server/discover
  → require resources + io.modelcontextprotocol/skills
skills/list
  → choose an entry, or start from an explicit skill URI
skills/get(uri of SKILL.md)
  → hold that skill entry and its resource manifest
resources/read(SKILL.md when loaded; supporting files when needed)
  → verify size/digest when supplied; compare SKILL.md frontmatter

The current extension requires a declaring server to implement both listing and retrieval by URI. A skill omitted from a partial listing can still be retrieved through skills/get. Directory reads require the separately advertised directoryRead: true capability. Do not send that optional method just because ordinary resource reads work.

Separate discovery, integrity and authority

Question	Contract or responsibility
How is a skill represented?	Agent Skills directory and `SKILL.md` format
How does a remote client find it?	MCP Skills discovery and direct URI lookup
Which bytes belong to the selected entry?	Held resource manifest, digests and the extension’s dynamic-resource rules
Who is allowed to install or follow it?	Host trust policy and user authorization
How are several components shipped together?	A package system such as Agent Plugins; not an automatic effect of reading a skill

A digest binds returned bytes to an entry; it does not make the publisher trustworthy. The stable specification’s retrieval rules prohibit prefetching files on connection, listing or approval: load SKILL.md at activation and supporting files when read. Approval can bind to the held manifest before retrieval. Reject a size, digest or frontmatter mismatch; the frontmatter check also applies to dynamic entries. Skill text remains external instructions, not permission to override the user’s intent.

A useful implementation check is to serve one immutable skill, verify its manifest, change one supporting file without changing its digest, and confirm that the host refuses to use the inconsistent content. That is a suggested local test, not a test result from this guide.

Where UHP fits

MCP Skills distributes instructions across the tool/context boundary. UHP Harness Plugins bind Agent Plugins packages to configured harnesses. Agent Skills describes the reusable instruction format. These layers can compose, but support for one does not imply support for the others. Continue with MCP resource-write maturity if your use case needs mutation rather than reading.

Historical source notes — baseline reviewed 16 Sep 2026

The following evidence preserves the earlier review and its links. “Current”, “stable” and “main” inside this section refer to that historical cutoff; they are not new release or compatibility claims. Use the guidance above for the current scope.

Current status

SEP-2640 (Skills Extension) is now a Final Extensions Track SEP merged into the canonical modelcontextprotocol/modelcontextprotocol repository. Commit 8075db4a changed the SEP from Accepted to Final on 11 September 2026, commit 1fc90489 added the Final-SEP historical-record notice, and PR #2640 merged on 13 September 2026 at merge commit 1eb5bbe8.

One minute later, PR #3353 merged the official Skills extension overview and client-support tracking at 2997f33b. The canonical MCP documentation now describes the io.modelcontextprotocol/skills extension, its skills/list / skills/get methods, optional resources/directory/read, capability negotiation, manifest integrity rules, security requirements and client support matrix.

On 16 September 2026, modelcontextprotocol/ext-skills PR #146 removed the repository’s former Experimental incubation framing and made specification/stable/skills.mdx the explicit source of truth for the released Skills extension. The repository now describes itself as the home of the official io.modelcontextprotocol/skills extension plus the Working Group’s decision log and design material; earlier pre-v1 design documents were moved under docs/archive/.

Later the same day, PR #147 merged at 34315ab7 to align that released stable page with the already-final SEP and official website. The correction restores the Agent Skills backwards-compatibility clause, makes server/discover and the required base resources capability explicit, states that every request still carries the required _meta request metadata even where examples omit it for brevity, replaces abbreviated/inconsistent digest-and-size examples with internally consistent values, and marks archived design documents as historical context. The PR explicitly classifies this as editorial alignment of established requirements, not a new extension proposal.

Those repository/specification corrections still need a boundary: they are not a new MCP base-spec revision and they do not establish universal deployed support. The released MCP specification remains 2026-07-28; Skills remains an opt-in extension, and stable SDK/host implementation support is still product-specific.

Surface	Current evidence
Standards proposal	SEP-2640 · Extensions Track · Final
Canonical repository	PR #2640 merged to `modelcontextprotocol` `main` at `1eb5bbe8`
Official documentation	Skills extension overview/support tracking merged at `2997f33b`
Extension identifier	`io.modelcontextprotocol/skills`
Extension specification	`modelcontextprotocol/ext-skills/specification/stable/skills.mdx` · released source of truth · Final-SEP alignment at `34315ab7`
Official conformance	`modelcontextprotocol/conformance` PR #330 merged to `main` at `7169291e`
Official client matrix at 16 Sep cutoff	ChatGPT, fast-agent and MCP Inspector are each listed Partial
SDK implementation status	Official Go, TypeScript, Python and C# work remains in progress/open at this cutoff
Stable publication boundary	Final SEP + canonical extension docs + stable extension spec; not a new base-spec version and not evidence every SDK/host has shipped support
Skill format authority	Separate Agent Skills specification; SEP-2640 defines the MCP transport binding

The current ext-skills implementation tracker records official Go, TypeScript, Python and C# SDK work as in progress. Fresh PR checks confirm Go SDK #1238, TypeScript SDK #2818, Python SDK #3485, and both C# candidates #1864 / #1856 are still open, so this site does not turn repository graduation into a claim that those SDK changes have shipped. PR #330 is merged into the official conformance repository’s main branch at merge commit 7169291e. That gives SEP-2640 a durable, runnable conformance surface; it does not turn every MCP host or SDK release into evidence of deployed support.

Official conformance now has a merged SEP-2640 suite

The official MCP conformance repository merged PR #330 on 11 September 2026. The merged traceability file declares 96 rows across 97 RFC 2119 sentences: 89 checks and 7 explicitly excluded requirements. Of the 89 checks, 40 are exercised on the wire by the server scenarios; the remainder are client/host obligations, including five that the PR also exercises by running the harness in the opposite direction against deliberately hostile server behavior.

The merged suite contains three server-facing scenario families and five client-facing verification scenarios:

sep-2640-skills-enumeration covers skills/list / skills/get, pagination, capability declaration, the {uri, frontmatter, resources} entry shape, dynamic, digests, sizes and the 512-resource / 16 MiB limits.
sep-2640-skills-manifest covers the served SKILL.md resource and its name/description/frontmatter and metadata consistency.
sep-2640-skills-directory covers optional resources/directory/read behind the directoryRead capability gate.
Five client scenarios test no prefetch, digest verification, size verification, frontmatter verification, and refusal to read an unlisted resource URI.

The PR reports green runs against three independent implementations: the official Go SDK implementation branch, the official C# SDK implementation branch, and mcpkit’s ext/skills, on both the 2026-07-28 and 2025-11-25 wires where applicable. The older wire legitimately skips the ttlMs / cacheScope check because those fields are not defined there; a SKIP in that case is version gating, not a conformance gap.

This suite is meaningful because it separates wire-observable conformance from requirements a protocol harness cannot prove, such as what a host displayed to a user or whether internal cache isolation was implemented correctly. It also records defects found by cross-implementation testing, including pagination handling and protocol-version-sensitive cache-attribute grading. Do not read the 89-check traceability count as 89 directly executable wire assertions.

What SEP-2640 standardizes

The extension does not invent another skill-file format. A served skill must conform to the separate Agent Skills specification, including the required root SKILL.md. SEP-2640 defines how an MCP server can expose that material through MCP’s Resources model.

The Final SEP defines these key surfaces:

A server declares io.modelcontextprotocol/skills in its server/discover capabilities. Because skill files are delivered through the base Resources primitive, a server declaring the extension MUST also declare the resources capability.
Every request MUST include the required MCP request _meta metadata. The stable specification omits _meta from abbreviated request examples only for brevity.
Each file in a skill can be exposed as an MCP resource, conventionally under skill:// URIs such as skill://git-workflow/SKILL.md.
A server declaring the extension implements skills/list to enumerate the skills it serves. The result may be empty or partial for large, generated or otherwise unenumerable catalogues.
skills/get retrieves the entry for one skill by URI, including a skill that is not present in the listing.
Optional resources/directory/read gives scoped navigation of direct children inside a directory resource; clients must not call it unless the server declared directoryRead: true.
The extension delegates directory structure, YAML frontmatter, naming rules and progressive disclosure to the Agent Skills specification rather than redefining them.
If a future Agent Skills revision is backwards incompatible, clients MUST honor that specification’s compatibility mechanisms and SHOULD continue supporting the pre-break Agent Skills behavior.

That makes Skills Over MCP a distribution and discovery layer for workflow know-how. MCP tools can describe what operations are callable; an Agent Skill can carry richer multi-step instructions for how an agent should orchestrate those operations.

The security boundary is materially different from ordinary tool invocation

The Final SEP treats remotely served skills as untrusted context with additional host-side risk. This matters because a skill can contain instructions, supporting files and scripts that influence what the model attempts locally.

The current text requires or recommends several important controls:

The model must be able to distinguish MCP-served skill content from local skill content and see its originating server identity.
MCP-served skills must not gain implicit host-side code execution. Execution directed by the skill requires explicit per-skill user approval.
allowed-tools cannot silently widen the model’s tool or filesystem permissions for an MCP-origin skill; such a grant requires explicit approval.
Resource reads initiated while acting on a skill are origin-scoped to resist cross-server confused-deputy behavior; cross-origin reads require explicit approval.
Same-named skills from different servers or the local filesystem must remain origin-isolated rather than silently shadowing one another.
Activating a nested skill requires fresh consent; approval of an enclosing skill does not approve nested SKILL.md frontmatter.
Persisted approval is content-bound to the listed resource set and digests. A changed set requires re-approval.
Digests provide consistency evidence between advertised and fetched content, but are not a trust boundary because the serving origin supplies both the metadata and the bytes.

This is a stronger trust model than simply treating a skill as another text resource. It acknowledges that workflow instructions can become a bridge from remote context into local tool use and filesystem/code-execution authority.

Skills Over MCP and Agent Plugins solve wire-versus-package portability

The two efforts share the Agent Skills format but standardize different carriers. A Working Group design analysis — now explicitly archived as historical context rather than current normative text — described them as overwhelmingly complementary: SEP-2640 moves skills over the wire at runtime; Agent Plugins packages skills and MCP configuration on disk. A plugin’s mcp.json can even point to an MCP server that itself advertises io.modelcontextprotocol/skills.

Question	Skills Over MCP / SEP-2640	Agent Plugins `1.0.0`
Main purpose	Discover and serve Agent Skills through an MCP connection	Define a portable package containing Agent Skills and optional MCP server configuration
Primary carrier	MCP Resources plus Skills Extension methods	Filesystem package rooted at `plugin.json`
Skill format	Delegates to Agent Skills	Delegates to the same Agent Skills specification
MCP server configuration	Does not package a client MCP configuration	May include portable MCP server configuration in `mcp.json`
Package / installation boundary	Does not define a plugin package or marketplace	Defines the package format; installation source, distribution/marketplace policy, trust/permission UX and general sandbox policy remain host/client concerns rather than portable v1.0.0 package semantics
Dynamic/live distribution	Can serve authenticated, changing or per-principal skill catalogs at runtime	Installed package is a materialized snapshot until the host updates/replaces it

The previous wording on this page described installation/marketplace behavior as a core Agent Plugins contract. That was too broad. The portable package is core; a universal installation or marketplace protocol is not. Agent Plugins 1.0.0 defines the package model and client conformance rules, while its own future-considerations document explicitly leaves portable trust, permission UX, provenance, secrets and enterprise installation controls for future work.

The clean layer map is therefore:

Agent Skills       SKILL.md + files                 skill format
Skills Over MCP    skills/list/get + resources      live wire distribution
Agent Plugins      plugin.json + skills/ + mcp.json portable on-disk package
UHP Harness Plugins Agent Plugins 1.0.0 binding     package inside a hosted harness

These layers can compose without collapsing into one protocol. A UHP 2026-09-12 Harness Plugin can contain an mcp.json entry for an MCP server that serves SEP-2640 skills; the harness then reaches those remote skills through MCP. That architecture does not make Skills Over MCP part of UHP, does not turn the MCP server into a UHP server, and does not establish a standardized UHP↔SEP-2640 wire binding.

That archived Working Group analysis also distinguished static snapshot ingestion from live delivery. A host may use the Skills methods to fetch and materialize a skill into an installed package, while a live MCP path can preserve server-controlled catalog changes, authentication and revocation. Those are deployment patterns around the same Agent Skills format, not competing definitions of what a skill is.

See UHP vs Agent Plugins for the package/binding boundary and Harness Plugins for UHP’s Agent Plugins 1.0.0 hosted-harness semantics.

How this relates to UHP

UHP and Skills Over MCP operate at different layers:

Product / application
        │
        │ UHP: execute through a complete harness
        ▼
Complete agent harness
        │
        │ MCP: connect to an MCP server
        ▼
MCP server
        │
        │ SEP-2640: discover/read Agent Skills
        ▼
Agent Skill resources

UHP standardizes the client-to-complete-harness execution contract: tasks/responses, sessions, streaming, cancellation, files/artifacts and structured errors according to conformance class. Skills Over MCP standardizes an MCP transport binding for reusable workflow instructions.

They can compose, but composition is not adoption. A harness driven through UHP could use an MCP server that publishes skills without the MCP server becoming a UHP server, without the Agent Skill implementing UHP, and without establishing a standardized UHP↔Skills binding. No primary source reviewed here establishes such a binding or native UHP adoption through SEP-2640.

For the broader protocol-layer comparison, see UHP vs MCP.

What to watch next

SEP-2640 has crossed the Final lifecycle threshold, merged into canonical MCP main, gained official extension documentation, a released stable specification home and merged official conformance coverage. The next evidence that would materially change this page is:

stable MCP SDK/host releases that can be attributed to shipped Skills Extension support;
wider full-support entries in the official MCP client matrix;
a later released Skills extension revision produced from accepted Working Group decisions; or
later normative extension/specification/changelog text that changes the Final design.

Until then, describe SEP-2640 as a Final Extensions Track SEP with official MCP documentation, a released stable extension specification and merged conformance coverage, while keeping the unchanged 2026-07-28 base-spec version and implementation-specific client/SDK support separate.

Choose an integrity path for the selected skill

Implement the transport, not a new package format

A minimal retrieval lifecycle

Separate discovery, integrity and authority

Where UHP fits

Current status

Official conformance now has a merged SEP-2640 suite

What SEP-2640 standardizes

The security boundary is materially different from ordinary tool invocation

Skills Over MCP and Agent Plugins solve wire-versus-package portability

How this relates to UHP

What to watch next

Primary sources