[FEATURE] Install skills published by MCP servers through the skills extension (SEP-2640) #3721

Proposals are welcome before implementation, so this is a proposal for discussion, not a request to accept a design.

Is your feature request related to a problem? Please describe.

MCP now has a standard way for a server to publish Agent Skills. APM installs skills from git, local paths, marketplaces and (experimentally) REST registries, and it installs MCP servers through dependencies.mcp. It has no way to treat the skills an MCP server publishes as an installable, lockable source.

People who run or connect to an MCP server that publishes skills (an internal platform team's server, a vendor's server, a gateway) currently have two choices. They rely on each agent host to support the extension, which few do yet, or they copy the skills into a git repo by hand so APM can install them. The second choice loses the link to the publisher and goes stale.

What the extension is

SEP-2640 reached Final status. It defines how an MCP server serves Agent Skills using the existing Resources primitive, under the extension id io.modelcontextprotocol/skills:

• skills/list enumerates the skills a server publishes. skills/get returns one skill's entry by URI.
• Each file of a skill is a resource, normally at skill://<skill-path>/<file-path>, so SKILL.md and its supporting files load one at a time, when needed.
• Every listed file carries a SHA-256 digest and a size, and a host verifies content against the digest.
• Skill names resolve per origin, so a served skill cannot silently take the place of a local one.

Working group repo: https://github.com/modelcontextprotocol/ext-skills

Describe the solution you'd like

Let a dependency name an MCP server that declares the skills extension, and install the skills it lists the same way APM installs any other skill.

• The server's skills/list result maps closely onto what APM already records. Each file has a URI, a SHA-256 digest and a size, which is the information apm.lock.yaml needs to pin and later verify a deployment.
• apm install would replay the locked digests. apm update would re-read the listing and show what changed, under the existing confirmation gate.
• Skills would deploy to each target's native skills directory unchanged, so they behave like every other installed skill on hosts that do not support the extension themselves.
• Existing policy controls (allowed sources, security scan, lifecycle scripts) would apply as they do to other sources.

I would know it works when a skill published by an MCP server can be installed, pinned, audited with apm audit --ci, and updated, with no manual copy step.

Important boundaries: the extension describes served skills as carrying the trust of the server they came from, and asks hosts not to let them silently replace local skills. APM turning a served skill into a local file is an explicit, user-approved install, but the lockfile should probably record the server origin so that provenance is not lost.

Describe alternatives you've considered

• Waiting for every agent host to implement the extension. That solves live loading, but gives no lockfile, no audit, and no coverage for hosts that never implement it.
• Mirroring a server's skills into a git repository with a script. This works today and is what the feature would replace.
• A REST registry in front of the server. That needs the publisher to run a second protocol for the same content.

Additional context

A smaller first step could be recognising, when APM installs an entry under dependencies.mcp, that the server declares the skills extension, and reporting that in the install output.

I am happy to help test against a server that implements the extension.