Skills over MCP is an official extension: the security rules hosts must follow

Agent skills, folders of instructions with a SKILL.md file that teach an agent how to do a task, have so far been shipped as files next to the agent. A new official extension to the Model Context Protocol changes that. SEP-2640, the Skills extension, defines how an MCP server can serve skills alongside its tools, so that any connected agent can discover them and load them when needed. It has reached Final status. For teams that run MCP servers or let developers connect to them, the most useful part is not the transport. It is the list of security rules a host must follow before it lets a served skill do anything.

What the extension defines

The extension has the identifier io.modelcontextprotocol/skills. It deliberately does not define a new skill format: the folder structure, frontmatter and naming rules all come from the existing Agent Skills specification. SEP-2640 only defines how those files travel over MCP.

Each file in a skill is exposed as an ordinary MCP resource, conventionally under a skill:// address such as skill://git-workflow/SKILL.md. On top of that, the extension adds:

• skills/list, which every server that declares the extension must implement, and which returns each skill's name, description and other frontmatter plus a manifest of its files;
• skills/get, which returns the same entry for one skill by its address, including skills that are not in the listing;
• an optional resources/directory/read, for browsing the files in a skill folder.

The SEP gives the motivation plainly. Without it, a server and the skill that teaches an agent to use it are versioned and installed separately, server instructions are too small for complex workflows, and several projects had already invented incompatible skill:// schemes.

Bloomberg, which helped standardise the extension, wrote on 21 October that it was announced at AGNTCon + MCPCon Europe in Amsterdam, and that Bloomberg was one of the first organisations to implement an early draft, in May, for its agentic assistant on the Bloomberg Terminal. It also notes that the protocol changed considerably between that draft and the final version.

What is not ready yet

The extension overview is clear that the specification being final does not mean it works everywhere: "SDK and host support is still being implemented". Before you plan around it, check whether your MCP clients and SDKs support it today. Don't assume that an AI tool which reads local skills will also load skills from an MCP server.

The security rules

The SEP's security section is the part to read in full. Its starting point is that skill content is instructional text delivered to a model, so it is a prompt-injection surface. The main requirements on hosts are these:

• Served skills are untrusted input. Connecting a server does not make its skills authoritative, and skills must not be treated as higher-authority than other context.
• Origin stays visible. Hosts must tag served skill content with the server it came from when it enters the model's context, and must not present it as if it were a local skill.
• No implicit code execution. A served skill must not cause code to run on the host without explicit approval for that skill. This covers fields the host parses, such as hooks, and instructions in the body that tell the model to run a bundled script or an arbitrary command.
• No implicit permission grants. The Agent Skills allowed-tools field, which widens the tools available while a skill runs, must be ignored for skills that arrive over MCP unless the user has approved that grant.
• Reads stay with their origin. A skill from one server must not cause the host to read resources from another server without approval naming both.
• Names are namespaced. A malicious server could publish a skill under the name of a popular one. Hosts must resolve names per server and must not let a served skill silently replace one from elsewhere, including the user's own local skills.
• Approval is tied to content. If a host remembers an approval, it is bound to the exact set of files and digests seen at the time. If any file changes, the approval is revoked and the user is asked again. Nested skills need their own approval.

The SEP also says plainly that the digests in a listing "are not a security boundary": they are unsigned and come from the same server as the content, so they show consistency, not trust.

The extension's own summary of the risk is direct: unlike a remote tool call, a served skill "can place server-authored bytes on the host filesystem and direct the model to execute them". Hosts are required to treat skills as a higher-risk surface than tools.

What it means for engineering and security leaders

Skills over MCP is a reasonable answer to a real problem. Teams that build internal MCP servers can now ship the instructions for using their tools with the tools, and update them in one place. For an organisation with many teams, that is easier to manage than copying skill folders onto every machine.

It also moves trust. A skill on disk was something a person installed. A skill served over MCP is whatever the server sends today, and the SEP notes that a name carries no authorship or endorsement. Much of the protection depends on hosts implementing these rules correctly, especially the per-skill approval before any script runs and the re-prompt when content changes. Those are host features, so they will vary between AI tools while support is being built.

For security teams, the practical question becomes which MCP servers your developers' tools connect to, because each one can now offer instructions as well as tools. We looked at a related risk in agent skills that link to bad domains.

Practical takeaways

• Check whether the AI tools and SDKs your teams use support the Skills extension yet, and how each one shows a skill's origin and asks for approval.
• Before turning it on, decide which MCP servers are allowed to serve skills, separately from which may serve tools.
• Don't allow served skills to run scripts without per-skill approval, and confirm that a changed skill triggers a new prompt.
• If you publish internal MCP servers, keep their skills in version control and review changes like code.
• Watch for skills with familiar names from unfamiliar servers.

SpanDock handles skills differently, by installing them as files rather than serving them over MCP. Its skills feature, in beta, lets an administrator turn a skill on once so every computer gets it, kept up to date. Skills that run scripts are marked as such, and a computer installs them only if its settings allow scripts, which they don't by default. If a person already has a skill with the same name, theirs stays and the managed one is not installed on that computer. Publishing your own skills is on the Premium and Enterprise plans.