Repository navigation
Open
Description
Executor already serves skills to agents through its own skills tool. This asks for the same skills to also be published through the standard MCP skills extension, so that any host implementing the extension can discover them without knowing anything about Executor.
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/listenumerates the skills a server publishes.skills/getreturns one skill's entry by URI.- Each file of a skill is a resource, normally at
skill://<skill-path>/<file-path>, soSKILL.mdand 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
Why it is worth doing in Executor
- Hosts can treat served skills as skills. A tool that returns skill text is opaque to a host. The host cannot list those skills in its own skill menu, apply its own consent rules, or cache them. With
skills/listthe host sees name, description and file list in a shape it understands. - Less for the model to learn. Today the model has to be told that an Executor-specific tool exists and how to page through it. A host that supports the extension handles discovery itself.
- Integrity comes for free. Executor already computes a revision hash for an app's skill catalog. Per-file digests are the standard form of the same idea, and hosts are required to check them.
- A gateway is where this matters most. Executor sits between agents and many apps. Publishing each app's skills through one standard listing means one connection gives a host every skill the person has access to, scoped by the access rules Executor already enforces.
- Pass-through. MCP servers that Executor connects to may start serving skills this way. Executor could relay them alongside app skills.
Suggested scope
- Declare
io.modelcontextprotocol/skillsand implementskills/listandskills/getover the catalog theskillstool already reads. - Expose skill files as resources under
skill://<app>/<skill>/..., with digests and sizes. - Keep the
skillstool for hosts that do not support the extension.
An earlier pull request (#1986) declared this extension before it was closed ahead of the v2 launch, so some of the design work may be reusable.
Open questions
- Skill files in Executor are UTF-8 text today (see [bug] githubSkills fails a whole repository on one binary file or one skill's frontmatter #2512). The extension addresses files as raw bytes, so binary assets would need a decision.
- Whether listing should reflect the per-caller view (linked accounts, app access), which the extension allows since a listing is per connection.
Metadata
Metadata
Assignees
Labels
No labels
Activity