Summary
There's an in-progress MCP extension, "Skills over MCP" (SEP-2640, spec repo:
https://github.com/modelcontextprotocol/ext-skills), being developed by a
dedicated working group. It lets an MCP server expose reusable workflow
instructions (a SKILL.md + supporting files, following the Agent Skills
format) that clients can discover (skills/list/skills/get) and load
on demand via the existing resources/read primitive.
Why this could matter for us
We already have workflow-shaped knowledge that currently only lives as prose
(docs/, tool descriptions, README), which a model has to infer rather than
load explicitly. Candidates for a future skill:
- When to use
static_map_image_tool vs render_map_tool
- Chaining
isochrone_tool → category_search_tool → render_map_tool for
coverage/site-selection analysis
- The
place_details_tool dual-API logic (Places API vs legacy boundary
fallback)
We already adopt other MCP extensions this way (@modelcontextprotocol/ext-apps
backs render_map_tool's interactive UI via MapAppUIResource), so this would
follow an established pattern in this codebase.
Current status (as of 2026-09)
- Spec-only — no reference SDK/npm package published yet from the
ext-skills repo.
@modelcontextprotocol/sdk@1.30.0 (currently pinned here) has no skills
support.
- Not actionable yet; revisit once the spec lands in the main MCP repo and
an SDK/ext-skills package ships (mirroring how ext-apps shipped).
Next steps
Summary
There's an in-progress MCP extension, "Skills over MCP" (SEP-2640, spec repo:
https://github.com/modelcontextprotocol/ext-skills), being developed by a
dedicated working group. It lets an MCP server expose reusable workflow
instructions (a
SKILL.md+ supporting files, following the Agent Skillsformat) that clients can discover (
skills/list/skills/get) and loadon demand via the existing
resources/readprimitive.Why this could matter for us
We already have workflow-shaped knowledge that currently only lives as prose
(docs/, tool descriptions, README), which a model has to infer rather than
load explicitly. Candidates for a future skill:
static_map_image_toolvsrender_map_toolisochrone_tool→category_search_tool→render_map_toolforcoverage/site-selection analysis
place_details_tooldual-API logic (Places API vs legacy boundaryfallback)
We already adopt other MCP extensions this way (
@modelcontextprotocol/ext-appsbacks
render_map_tool's interactive UI viaMapAppUIResource), so this wouldfollow an established pattern in this codebase.
Current status (as of 2026-09)
ext-skillsrepo.@modelcontextprotocol/sdk@1.30.0(currently pinned here) has noskillssupport.
an SDK/
ext-skillspackage ships (mirroring howext-appsshipped).Next steps
render_map guidance) as a proof of concept
src/skills/(mirroringsrc/resources/structure)is the right home