MCP Can Serve Agent Skills Now: What Builders Need to Know

An MCP server can expose tools, resources, and prompts. The newly finalized MCP Skills extension adds a way for that server to publish agent skills too: instructions that tell an agent how to use those capabilities in a workflow. The distinction matters. A tool can issue a refund; a skill can explain the checks, approval steps, and sequence for handling a refund request.

The extension’s specification is final, not its rollout. At the September 22 working-group meeting, maintainers described SDK and host implementations as ongoing work. Developers should read this as a new interoperability contract to evaluate, not a promise that every MCP client can load remote skills today.

How the extension works

The server declares io.modelcontextprotocol/skills in its capabilities, alongside the base resources capability. A compatible client can call skills/list to discover entries or skills/get to retrieve one by its SKILL.md URI. The actual files are read using MCP’s existing resources/read method. Servers may also support resources/directory/read for listing files inside a skill directory, but clients must check that optional capability before using it.

A skill remains a directory with a SKILL.md file and YAML frontmatter containing at least name and description. The extension does not invent a new skill format. It maps the existing Agent Skills format onto MCP resources. A typical entry might point at skill://acme/billing/refunds/SKILL.md; supporting files have their own resource URIs. The server could use another URI scheme, so clients should not assume that skill:// is the only valid shape.

Each entry carries the skill’s frontmatter and a file manifest with byte sizes and SHA-256 digests. That lets a host inspect the proposed skill and check retrieved bytes against the manifest. Dynamically generated skills can instead declare resources: "dynamic", which means the host cannot make the same content-bound integrity check and may refuse to load them. A manifest is an integrity mechanism, not proof that the instructions are safe or that the publisher is trustworthy.

Why serve instructions next to tools?

Consider a team with an internal billing MCP server. Its tools may retrieve an order, check payment state, and create a refund. Without workflow guidance, an agent still has to infer which checks are mandatory and when a human must approve the write. A server-published refund skill could carry those instructions, examples, and policy references with the integration itself.

That is useful when a host has no local filesystem for installing skill folders, or when a team already distributes its tools through MCP. The working group was careful about the opposite case. In its September 22 discussion, a team building a local CLI directory asked whether it should switch to the extension. The guidance was conditional: if the CLI already handles skill access and distribution, forcing MCP into the path may add complexity without solving a present problem. Remote or web-based hosts have a clearer reason to consider it.

This is not skills versus MCP servers. It is skills delivered through an MCP server. A local skill still makes sense for repository-specific conventions. A server-served skill makes sense when the instructions belong to the integration and should travel with it.

The security boundary is the real design test

Remote instructions can ask an agent to do things. That makes skill loading a different decision from discovering a tool name. The specification requires hosts to keep a skill’s originating server attached to its URI: two servers may both publish skill://refunds/SKILL.md, and those must not collapse into one identity. Same-named local and remote skills must not silently replace one another. Nested skills require their own explicit approval before activation.

For a production host, the useful question is not merely “Can I list these skills?” It is “Can I show the user which server supplied this skill, what files it contains, whether the content changed, and what authority it requests?” The spec describes the protocol boundary, but the host still needs a usable approval flow and a policy for untrusted instructions. The same caution applies when evaluating any MCP integration.

What is ready and what is not

The meeting notes say the Skills extension proposal reached Final status on September 13 and its documentation is published. They also describe implementation work in TypeScript, Python, and C# SDKs, ongoing conformance updates, and open questions about how skills compose with Tasks, events, and apps. A final protocol text and widely available client support are separate milestones.

If you maintain an MCP server, start by inventorying any instructions currently buried in server descriptions or scattered across README files. Decide whether they are general tool documentation or a reusable workflow that deserves a skill. If you build a host, test discovery, per-server identity, file verification, approval, and behavior when the extension is absent. Do not assume that publishing a skill makes every client aware of it.

There is a directory angle too. A listing such as the AgentNDX skills directory helps developers find candidates, while a server-published manifest tells a compatible host which files that particular server serves. Neither substitutes for checking the publisher, installation path, and runtime behavior. Our install-command audit found that even ordinary local skills can have ambiguous setup instructions. Remote delivery changes the mechanism; it does not remove the need to verify what runs.

FAQ

Does this replace locally installed agent skills? No. The extension defines a way to serve the same skill format over MCP. Local skills remain useful, especially for project-specific instructions and clients without extension support.

Does Final mean my MCP client supports it? No. Final refers to the extension specification. Check your client’s and server SDK’s implementation status and test both discovery and file loading before relying on it.

Can I trust a digest in the skill manifest? A digest can detect a mismatch between the listed content and retrieved bytes. It does not establish that the server is trustworthy or that the skill’s instructions are safe. Review the source and require appropriate approval before activation.