Proposal
I'd like us to support the Skills over MCP extension so our MCP servers can publish workflow instructions alongside their tools. Start with skills bundled and versioned with Azure MCP Server, with the protocol support structured for reuse by other servers in this repo.
The server supplies the skill. The host discovers, verifies, and loads it. We should not require the server to install files into a client's skills directory or introduce a custom download tool for functionality the extension already defines.
Problem
Tools expose individual operations, but they do not always provide enough guidance for a workflow that spans several operations. Maintaining that guidance separately from the server creates another installation step and allows instructions to drift from the tools they describe.
Shipping skills with the server keeps the instructions and tool implementations aligned. A compatible host can discover the available workflows and load the relevant instructions when needed.
Proposed behavior
The server would declare Resources support and the io.modelcontextprotocol/skills extension, then implement:
skills/list to expose skill frontmatter and complete file manifests, including SHA-256 digests and byte sizes.skills/get to retrieve a skill entry directly by URI, including skills not returned by the listing.resources/read to return SKILL.md and supporting files on demand.
Directory reading is optional in the extension and can remain out of the initial implementation unless a supported client requires it.
For example, a deployment diagnostics skill could describe the investigation sequence, reference troubleshooting guidance, and direct the agent to the appropriate MCP tools. The host retrieves the instructions first and supporting files only as needed. Reading a skill does not activate it or execute its scripts.
Local MCP behavior
This should work over stdio as well as HTTP. A locally running server reads bundled skill content and returns it through MCP. It does not need an HTTP endpoint or a shared filesystem with the host, so the same approach works when the server runs in a container or WSL.
Retrieving bundled skills should not require network access. The operations described by a skill may still require Azure connectivity and authorization.
The host owns skill activation, approval, and caching. The server should not write into the user's repository or client-specific skill directories. MCP resource URIs identify published content, not arbitrary paths on the server's filesystem.
Scope and boundaries
Start with static, bundled skills and manifests generated from the exact bytes served. Defer upstream catalogs, independently updated skills, dynamic content, and a separate installation or export experience.
Follow the extension's integrity and origin requirements rather than inventing a parallel trust model. Hosts must retain server identity and skill URI, verify retrieved content, and apply the required approvals. Serving a script does not authorize its execution, and a skill does not grant additional tool permissions.
Client support is a dependency. Confirm the protocol revision, SDK support, and intended host's implementation before committing to the integration. Clients without Skills support must continue to use existing tools normally; exposing resources alone does not provide native skill activation.
Acceptance criteria
References
Proposal
I'd like us to support the Skills over MCP extension so our MCP servers can publish workflow instructions alongside their tools. Start with skills bundled and versioned with Azure MCP Server, with the protocol support structured for reuse by other servers in this repo.
The server supplies the skill. The host discovers, verifies, and loads it. We should not require the server to install files into a client's skills directory or introduce a custom download tool for functionality the extension already defines.
Problem
Tools expose individual operations, but they do not always provide enough guidance for a workflow that spans several operations. Maintaining that guidance separately from the server creates another installation step and allows instructions to drift from the tools they describe.
Shipping skills with the server keeps the instructions and tool implementations aligned. A compatible host can discover the available workflows and load the relevant instructions when needed.
Proposed behavior
The server would declare Resources support and the
io.modelcontextprotocol/skillsextension, then implement:skills/listto expose skill frontmatter and complete file manifests, including SHA-256 digests and byte sizes.skills/getto retrieve a skill entry directly by URI, including skills not returned by the listing.resources/readto returnSKILL.mdand supporting files on demand.Directory reading is optional in the extension and can remain out of the initial implementation unless a supported client requires it.
For example, a deployment diagnostics skill could describe the investigation sequence, reference troubleshooting guidance, and direct the agent to the appropriate MCP tools. The host retrieves the instructions first and supporting files only as needed. Reading a skill does not activate it or execute its scripts.
Local MCP behavior
This should work over stdio as well as HTTP. A locally running server reads bundled skill content and returns it through MCP. It does not need an HTTP endpoint or a shared filesystem with the host, so the same approach works when the server runs in a container or WSL.
Retrieving bundled skills should not require network access. The operations described by a skill may still require Azure connectivity and authorization.
The host owns skill activation, approval, and caching. The server should not write into the user's repository or client-specific skill directories. MCP resource URIs identify published content, not arbitrary paths on the server's filesystem.
Scope and boundaries
Start with static, bundled skills and manifests generated from the exact bytes served. Defer upstream catalogs, independently updated skills, dynamic content, and a separate installation or export experience.
Follow the extension's integrity and origin requirements rather than inventing a parallel trust model. Hosts must retain server identity and skill URI, verify retrieved content, and apply the required approvals. Serving a script does not authorize its execution, and a skill does not grant additional tool permissions.
Client support is a dependency. Confirm the protocol revision, SDK support, and intended host's implementation before committing to the integration. Clients without Skills support must continue to use existing tools normally; exposing resources alone does not provide native skill activation.
Acceptance criteria
References