Agent skills are moving to a shared library over MCP. A fingerprint proves the file, not the advice

Where should a skill live?

For most enterprise teams the honest answer today is “in several places.” A skill, the packaged instructions and reference files that teach an agent how to do a task the company’s way, starts in one agent’s folder. It works. Another team copies it. Six months later there are five versions, each slightly different, and nobody knows which one the claims agent is using.

Two releases on October 12 point to a different arrangement.

A standard, a preview and a beta

Microsoft published a technical walkthrough of the MCP Skills extension, identified as io.modelcontextprotocol/skills. Its proposal, SEP-2640, has reached Final status. The extension lets a server declare that it offers skills, list them with skills/list, and publish a manifest for each one: every file’s address, size and SHA-256 digest. The host, meaning the application running the agent, reads the instructions and supporting files only when needed and checks each against the manifest before using it.

Microsoft Foundry offers skills in preview. Teams upload a skill to create a fixed, versioned snapshot, then reference it from a toolbox that exposes tools and skills through one MCP endpoint. A toolbox can pin a skill version or follow its default. The preview has no service level agreement and Microsoft does not recommend it for production.

On the same day, Databricks released a Unity Gateway Skills API in beta, with operations to create, read, update, list, delete and finalize skills from its CLI and SDKs.

What the extension guarantees, and what it leaves to you

The useful part of Microsoft’s write-up is how carefully it separates what the protocol checks from what it cannot.

Who answers which question about a shared skill

The server and the protocol

• Which skills exist
• Exact file bytes, by size and digest
• Which version is served
• Which server it came from

Integrity and provenance

The host and the enterprise

• Whether the advice is right
• Whether it may be loaded
• Whether scripts may run
• Which tools the agent may call

Trust, approval and permission

The specification is strict on the host side. A host must track which server supplied a skill, because two servers can offer skills with the same name and they “must not silently replace each other.” It must reject a file whose size or digest no longer matches. Saved approval is tied to the file fingerprints, so if a refreshed manifest changes, adds or removes a file, “that approval is revoked and the host must ask again.” Reading a script does not grant permission to run it; host-side execution requires explicit user approval. And if a skill’s instructions tell the agent to use another tool, “that request is not permission to use it.”

Then the limit, stated plainly: “These checks tell you that the content matches what the server offered. They don’t tell you whether the content is safe or the instructions are good.”

Why a shared library changes the risk

Centralizing skills solves drift between copies, and that is a real gain. It also concentrates influence. A skill that tells a procurement agent how to evaluate suppliers, served from one library to forty agents, is now a procedure with forty executors. If it is wrong, or quietly edited, the error spreads at the speed of the next cache refresh.

That makes the skill library a controlled document repository, whether or not anyone calls it that:

• Authorship and review. Who may publish a new skill version, and who must approve it? Regulated procedures already have owners; skills that encode them need the same.
• Pinning by risk. Agents doing consequential work should pin a reviewed version. Following “the default” is fine for low-risk skills and dangerous for anything an auditor would ask about.
• Dynamic content. Servers may mark generated skills as dynamic when stable fingerprints are not available. Hosts may refuse them; for consequential work, they should.
• Portability. Skills held in a vendor runtime are part of the switching cost we described in agent memory and skills as the new lock-in. A standard reduces it only if your own repository remains the source and the vendor library a mirror.

Check the client before you plan

Microsoft’s testing is a useful warning about maturity. Its Foundry endpoint negotiated an older protocol revision (2025-11-25), accepted skills/list there, and rejected a request on the latest revision as unsupported. “Being able to call an MCP tool isn’t enough to discover and load remote skills.” Before designing around shared skills, check the extension support matrix for every host your agents run in.

MCP standardized how agents reach tools without governing them, the gap we described in MCP connectivity without MCP governance. Skills follow the same path. The protocol now delivers instructions with integrity. Deciding which instructions deserve to be delivered is still the enterprise’s job.