Skills Over MCP: SEP-2640 and Agent Skills distribution

Current status

SEP-2640 (Skills Extension) has been Accepted by the MCP Core Maintainers. The SEP sponsor recorded that status on 3 September 2026, and the current proposal branch marks the Extensions Track SEP as Accepted. The pull request is still open and unmerged, however, so Accepted must not be collapsed into Final, merged specification text, or a released stable extension.

The official Skills Over MCP Working Group incubation repository remains explicitly Experimental. Its README identifies SEP-2640 as the source of truth for the v1 specification text and says the remaining path to Final includes a reference implementation, conformance tests, and the extension repository/documentation work.

Surface	Current evidence
Standards proposal	SEP-2640 · Extensions Track · Accepted
Pull request	Open and unmerged at this verification cutoff
Extension identifier	io.modelcontextprotocol/skills
Incubation repository	modelcontextprotocol/ext-skills · explicitly Experimental
Stable/Final extension?	No — acceptance is not finalization or release
Skill format authority	Separate Agent Skills specification; SEP-2640 defines the MCP transport binding

Caution

The official Working Group charter still shows the Skills Extension work item as In Review. The newer primary evidence is the SEP sponsor’s 3 September acceptance announcement plus the proposal branch’s Accepted status. This page therefore records Accepted, not Final, while preserving that the charter text has not fully caught up.

What SEP-2640 standardizes

The proposal 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 current accepted proposal defines these key surfaces:

• 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.
• The extension delegates directory structure, YAML frontmatter, naming rules and progressive disclosure to the Agent Skills specification rather than redefining them.

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 accepted proposal 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 is not Agent Plugins

The two efforts solve adjacent but different portability problems.

Question	Skills Over MCP / SEP-2640	Agent Plugins
Main purpose	Discover and serve Agent Skills through an MCP connection	Package portable Agent Skills plus optional MCP configuration
Primary carrier	MCP Resources plus Skills Extension methods	Installable plugin directory/package
Skill format	Delegates to Agent Skills	Can package Agent Skills
MCP server configuration	Not a plugin/configuration bundle	Can include MCP configuration
Installation/marketplace format	Out of scope for the WG	Core purpose of the package format

The Skills Over MCP charter explicitly keeps general plugin/bundle packaging out of scope. See UHP vs Agent Plugins for that separate packaging boundary.

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 a proposed 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

The maturity threshold is now clearer than when SEP-2640 was merely under review. The next evidence that would materially change this page is:

1. the SEP reaching Final and landing in the canonical MCP specification repository;
2. the extension’s reference implementation and conformance tests becoming the accepted interoperability baseline;
3. stable MCP SDK/host support that can be attributed to released versions rather than prototypes; or
4. a later MCP specification release formally carrying the extension.

Until then, describe SEP-2640 as Accepted but not Final/released.

Primary sources

• SEP-2640: Skills Extension
• SEP sponsor acceptance update — 3 Sep 2026
• Skills Over MCP Working Group incubation repository
• Skills Over MCP Working Group charter
• Agent Skills specification
• MCP 2026-07-28 specification