* docs: add skills-extension-candidates tracker
Scaffold a candidates list for MCP servers, dev tools, SDKs, and
skills repositories that could adopt SEP-2640. Initial entries:
FastMCP 3.0 Skills, chrome-devtools-mcp, hf-mcp-server, Hugging Face
skills library, github-mcp-server (PR #2428 demo), Azure Skills Plugin.
Cross-link from related-work.md and add a row to the README docs
table.
* docs: add Issue/PR tracker column to candidates table
* docs: add client-mcp-support survey alongside candidates tracker
* docs: link Azure MCP Server source in candidates table
* docs: remove gemini-cli from client MCP support survey
* docs: verify hermes-agent, switch source refs to main-branch links, refresh takeaways
- Promote hermes-agent from first-pass to verified; note its per-server tool
pattern (`mcp_{server}_read_resource` + `mcp_{server}_list_resources`) and
confirm end-user docs exist
- Drop stale line numbers throughout; convert path refs to GitHub source-file
links on `main` (commit-pinned URLs decayed once files moved)
- Goose: PR #8989 has landed, so describe current `(extension_name, uri)`
required signature and drop the now-closed issue/PR tracking
- Takeaways: collapse to three implementation patterns (Goose now fits the
`(server, uri)` bucket), fix open-source count to fourteen, drop the
smolagents name-drop (not in survey), add strands-agents alongside mastra
for the internal-SDK-only pattern, and reframe the signature recommendation
around server-resolution reliability rather than URI portability
* docs: verify remaining first-pass clients, flip cline/Roo-Code to Yes
Verified adk-python, agent-framework, crewAI, mastra, cline, Roo-Code
against local source clones. Two corrections to prior state:
- cline and Roo-Code both expose access_mcp_resource(server, uri) as a
model-facing tool via McpHub.readResource. Flipped from No to Yes.
- adk-python's load_mcp_resource takes resource_names: array[string] in
a single call (not two-shot); opt-in via use_mcp_resources flag.
Headline count updated from six to eight of fourteen open-source clients
satisfying #2527. Cross-cutting observations and takeaways adjusted for
the new (server, uri) family members and the four-pattern signature
breakdown. Trust-model list extended.
* docs: add Figma and Adobe MCP as SEP-2640 testing candidates
* docs: update FastMCP 3.0 Skills entry with detailed notes on SEP-2640 compliance
* docs: drop unconfirmed Cursor SEP-2640 entry, track latest SEP-2640 wire-contract PRs
Remove the Cursor row + deep dive (reported WIP never confirmed). Add the
in-flight PRs realigning to the 2026-06-05/06-09 SEP-2640 schema (frontmatter +
archives[] index, resources/directory/read): hf-mcp-server#174, fast-agent#825,
huggingface/skills#172.
* docs: add Slack (interested) and Bloomberg (internal use) as SEP-2640 candidates
* docs: remove archived Roo-Code from client survey, update strands repo to harness-sdk
* docs: re-verify SEP-2640 implementations against current upstream main
Both reference implementations have migrated to the July 2026 v1 shape,
verified against fresh clones rather than the prior June commit pins:
- hf-mcp-server (d794b10, v0.4.6): skills/list + skills/get, per-file
{uri,digest} resources manifest, directoryRead:true, no index.json or
archives. Migrated in #219 (merged 2026-08-03). Also records the
snapshot/TTL model and HTTP-transport-only constraint.
- fast-agent (79b903c, 0.10.1): pins SEP-2640 revision d7490ec, treats
legacy index.json skill-md/archive entries as unsupported. Requires
--prerelease=allow (pins fastmcp-slim 4.0.0b1), per @evalstate.
Corrects the earlier note claiming implementations lagged the SEP: the
#174/#825/#172 round merged 2026-06-19 and was never in flight, and a
second realignment followed the v1 rework.
Also fixes drift found while re-checking fast-agent's resource tool:
smart_agent.py is gone (now core/harness_tools.py), get_resource is
opt-in via harness_tools (default False, was unconditional), and
server_name is now optional - the one surveyed client where the model
may omit server identity.
Runtime skill loading is still unshipped; #816 remains open.
🦉 Generated with [Claude Code](https://claude.com/claude-code)
* docs: track SEP revision 0eb05fe and add mcpkit to the candidates tracker
The SEP moved from d7490ec to 0eb05fe (2026-08-05). The delta is
editorial for the wire contract -- skills/list, skills/get, and the
per-file resources manifest are unchanged -- so d7490ec-pinned
implementations stay compatible. Records what it does change: a soft
reg-name constraint on the first skill-path segment, the skill root URI
fixed as skill://<skill-path> with no trailing slash, whether skills/get
carries ttlMs/cacheScope reopened, and normative host obligations in the
security section.
Adds mcpkit (panyam/mcpkit, Go, v0.3.0) from #118 as a candidate. It
implements the pre-v1 index.json catalog shape with per-file digests, so
the ecosystem is now split across draft revisions rather than uniformly
caught up.
🦉 Generated with [Claude Code](https://claude.com/claude-code)
* docs: refine mcpkit entry — deliberate tracking, partial v1 migration
Checked mcpkit's issues and PRs rather than inferring alignment from
code shape. Its lag is a tracked decision, not drift:
- #1185 (merged 2026-08-04) implements origin-tagging and per-origin
resolve citing SEP L179/L183/L185 -- the host obligations 0eb05fe made
normative -- so it is already on v1 for the security section. #1187
adds a SEP-2640 security/conformance harness as a WG demo.
- #780 is an explicit index-schema tracking issue that has absorbed the
archives removal and the resources:[{uri,digest}] direction but waits
on WG confirmation; its conformance fork pins provenance at 556154c.
- The carrier change is still unbooked: nothing references skills/list
or skills/get.
- Archives are kept as a non-spec extended surface rather than deleted,
unlike fast-agent -- a counter-case for whether deferring a feature
removes it from the ecosystem.
Sharpens the callout accordingly: the draft split runs within an
implementation, not only between them, so "which draft does X
implement" often has no single answer.
🦉 Generated with [Claude Code](https://claude.com/claude-code)
* docs: add skill-set to related work
Adds skill-set under Specifications and Standards as related work for deterministic whole-skill and set-level hashing, receipt-time verification, and out-of-band content pins.
* docs: add integrity and verification section
Move skill-set from Specifications and Standards into a new resource integrity and verification section.
* docs: sync repo SEP copy with canonical v1 text
The repo-local copy of SEP-2640 had drifted well behind the canonical
text on the sep/skills-extension branch, which was a source of
confusion: it still specified the well-known skill://index.json
resource and predated skills/list, skills/get,
resources/directory/read, nested skills, and per-file digests.
Replace the body with a verbatim copy of the canonical SEP as of
d7490ec (2026-07-15) and swap the stale "not actively maintained"
notice for a disclaimer that states what this file now is: a synced
snapshot, re-synced by overwriting rather than hand-editing, with
review on the upstream PR and anything beyond v1 raised as a PR in
this repository.
Also drop "working draft" from the README and related-work references
to this file, since it is no longer where the text is drafted.
* docs: frame the SEP copy as the v1 baseline for decision-log proposals
The previous note told readers not to propose changes here at all, which
is the wrong instruction: the WG does want to propose beyond v1, just in
this repo rather than on the upstream SEP.
Reframe the file as the v1 baseline and route proposals through the
existing decision log rather than a parallel mechanism. decisions.md
already carries the ADR-lite format, the Proposed/Accepted/Superseded
status idiom, and the precedent for consolidating a version's scope into
one record (the 2026-07-16 v1 entry), so a change beyond v1 is simply the
next dated entry. The note also defines the marker that ties an amended
section back to its record, so v1 text stays distinguishable from
accepted deltas as the document accumulates them.
Align the README and related-work references to the same framing.
* docs: mark the 2026-04-16 URI decision superseded in part
Every other decision the v1 scope-down changed carries a forward pointer
in its status line (2026-04-19, 2026-06-02, 2026-06-05, 2026-06-09). The
2026-04-16 URI entry was left as plain Accepted while three of its
bullets no longer hold, so it reads as current guidance for index.json
enumeration and the no-nesting rule.
Give it the same treatment, naming which bullets changed and which parts
of the URI convention carry forward, so the entry stays useful as a
record of the structure it settled.
* docs: add AGENTS.md and make the SEP PR link prominent
Readers were landing on the repo-local SEP copy and taking it for the
spec, which is how the stale version misled people in the first place.
Say plainly, in the places they land, that the v1 spec text lives on
modelcontextprotocol#2640:
- README: a source-of-truth line at the top of the link block, above
the charter.
- The baseline copy: lead the header note with the PR rather than
mentioning it mid-paragraph.
- AGENTS.md: state the rule for agents working in this repo, along with
how to propose beyond v1 via the decision log and the repo's markdown
conventions.
CLAUDE.md is a one-line pointer to AGENTS.md rather than a symlink, so
it resolves on Windows checkouts too, where symlinks need Developer Mode
and would otherwise land as a stub.
* docs: use the @AGENTS.md import in CLAUDE.md
A markdown link is not an import — Claude Code would have loaded the
pointer line and never expanded AGENTS.md into context. The documented
syntax is @path, which the docs specifically recommend over a symlink
on Windows, where symlinks need Administrator privileges or Developer
Mode.
The maintainer note is a block-level HTML comment, which Claude Code
strips before injecting the file, so it costs no context while staying
visible to anyone opening the file.
https://code.claude.com/docs/en/memory#agents-md
* docs: tighten AGENTS.md to the source-of-truth rule
Cut the project overview and conventions sections and lead with what an
agent most needs to get right: the v1 spec text is on the PR, and the
copy here is only as current as its pinned commit. CONTRIBUTING.md
already covers participation and process.
* docs: link Sam Morrow's Progressive Discovery in MCP (Part 2)
* docs: link Angie Jones's "Skills Over MCP" article
* docs: mark open-questions and experimental-findings as not actively maintained
* docs: soften approaches doc and mark SEP working draft as not actively maintained
The links pointed to anthropic-quickstarts, but the project lives at
github.com/ChromeDevTools/chrome-devtools-mcp. Also corrects the author
attribution from Anthropic to Google (ChromeDevTools).
* Update documentation for Skills Extension SEP and related resources
- Revised links and descriptions in README.md to reflect the submitted Skills Extension SEP (PR #2640).
- Updated current status in approaches.md to indicate submission of the Skills Extension SEP.
- Clarified tracking information in open-questions.md regarding the Skills Extension SEP submission.
- Adjusted related work in related-work.md to include the Skills Extension SEP and mark a rejected proposal.
- Changed status in sep-draft-skills-extension.md to 'submitted' and updated author information.
- Enhanced skill-uri-scheme.md to indicate the incorporation of feedback into the submitted Skills Extension SEP.
* Move rejected SEP-2093 to the bottom of SEPs and Proposals table
Keeps the list active-proposals-first so readers aren't distracted by the
struck-out entry.
🦉 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Mark SEP-2076 as closed and move to the bottom of proposals table
PR #2076 was closed without merge on 2026-02-24.
🦉 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Use SEP-2640 naming convention per MCP SEP guidelines
Per https://modelcontextprotocol.io/community/sep-guidelines, a submitted
SEP is named "SEP-<PR-number>". Rename in-repo references from "PR #2640"
to "SEP-2640" and update the draft doc heading from the "SEP-0000"
placeholder to "SEP-2640".
Also mark Approach 1's SEP-2076 status as closed (2026-02-24, no sponsor
found); approaches.md still listed it as "Draft, seeking sponsor".
🦉 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Fix SEP-2076 closure rationale
Closure followed the WG's decision to first explore a convention-based
approach using existing primitives, not a sponsor issue.
🦉 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Refine SEP-2640 description in README to clarify proposal details
* Link issues and meeting notes in Open Questions README row
🦉 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Surface SEP-2640 in README and related-work table order
README: move the Skills Extension SEP from the bottom of the Repository
Contents table to sit after Approaches, matching the narrative flow
(framing → options → proposal → supporting material).
related-work.md: lead the SEPs and Proposals table with SEP-2640 (this
WG's headline proposal), followed by the prerequisite PR #2527.
🦉 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Add 'Open work' link to README header pointing to open PRs
Signals that alternative proposals, decisions, implementations, and
other in-flight contributions are welcome — SEP-2640 is one direction,
not the only one.
🦉 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* docs: transition from Interest Group to Working Group
Follow-up to modelcontextprotocol/modelcontextprotocol#2586, which
converted the charter from IG to WG.
- Rename Interest Group → Working Group in headings and prose
- Update Discord (#skills-over-mcp-wg) and Discussions
(meeting-notes-skills-over-mcp-wg) references; channel renames
coordinated separately
- CONTRIBUTING.md: align meeting norms with MCP group governance
(7-day advance notice, meet.modelcontextprotocol.io) and rewrite
Decision-Making to reflect WG authority (lazy consensus → formal
vote → escalation), linking to the charter's Authority table
- Keep CODEOWNERS team at skills-over-mcp-ig pending access-repo
rename; TODO comment added
- decisions.md: update present-tense preamble, log the IG → WG
transition as a new ADR entry, and preserve historical entries
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* docs(contributing): link to governance/charter instead of duplicating
Meetings and Decision-Making sections now point to the MCP group
governance doc and charter for canonical rules, keeping only the
repo- or group-specific bits (notes location, coordination
channels, outputs list). Also drops a leftover "rough consensus"
IG-era phrase in the Decision Log guidelines.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* docs(codeowners): fix sentence fragment in default-owner comment
"Has day-to-day governance" read as an incomplete sentence and
overstated what CODEOWNERS actually encodes (review routing, not
governance). Replace with a direct one-liner.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Reorganize related-work.md to separate IG member work from community and ecosystem
The flat implementations list mixed IG facilitator/participant work with
community adoptions and tangentially related ecosystem projects, making it
hard to see which implementations are actively shaping the group's direction.
Changes:
- Split "Implementations" into "IG Member Implementations", "Community
Implementations", and "Related Ecosystem Work" sections
- Add Organization column to IG member table for clearer attribution
- Add skillful-mcp (Kurtis Van Gent / Google Cloud) as IG member impl
- Update my-cool-proxy attribution to Jack Tysoe / Kong
- Split "External Resources" into "Specifications and Standards" and
"Background Reading"
- Move Cloudflare RFC from Open SEPs to Specifications (it's a published
spec, not a proposal to this group) and update to v0.2.0 with correct
path (/.well-known/agent-skills/)
- Update implementation notes with recent version/feature info
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Rename section header from "Community Implementations" to "Other Community Implementations" for clarity in related work documentation
* Fix my-cool-proxy attribution and move to community implementations
karashiiro (Kara) is not Jack Tysoe from Kong — incorrectly conflated
the two based on "MCP gateway" mention in meeting notes. Move
my-cool-proxy back to community implementations with correct author.
Also incorporates the section rename to "Other Community Implementations"
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Move NimbleBrain to community implementations
NimbleBrain (Mathew Goldsborough) has one comment on the IG repo and was
referenced in the inaugural meeting notes, but hasn't attended meetings
or filed issues/PRs. Better categorized as a community implementation.
Kurtis Van Gent stays in IG member table — he's an MCP core maintainer.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Separate IG member work by alignment with core patterns
After reviewing the actual implementations against the IG's direction
(SKILL.md frontmatter, skill:// URIs, progressive disclosure via MCP
primitives), three repos directly implement those patterns while three
take alternative approaches worth documenting separately.
Core pattern implementations:
- skilljack-mcp: full SKILL.md + skill:// + progressive disclosure + dynamic updates
- skills-over-mcp: SKILL.md + skill:// resources + Zod validation
- skillsdotnet: SKILL.md + skill:// + load_skill tool + NuGet published
Alternative approaches (still by IG members):
- skillful-mcp: progressive disclosure via tools wrapping MCP servers (no SKILL.md)
- astronomer-agents: production SKILL.md catalog via plugin marketplace (not MCP resources)
- mcpGraph: tool orchestration engine with SKILL.md as docs (not runtime skills)
Also enriched implementation notes with specific technical details from
code review rather than surface-level descriptions.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Rename section to 'Alternative Approaches' — Kurtis is MCP maintainer, not IG member
skillful-mcp is by Kurtis Van Gent, an MCP core maintainer who has
commented on IG work and written a relevant blog post, but is not an
IG member. Broaden the heading to include MCP maintainers alongside
IG members.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Add PR #2527 (model access to resources) to Open SEPs
This spec PR recommends clients expose resource read to models, which
is a prerequisite for the resources-based skills approach. Discussed in
the April 7 IG meeting as a primary blocker — skills as resources only
work if models can actually read them.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Add community insights from Discord threads and meeting notes
Distill Discord discussions (Feb 14-24) and Feb 26 office hours into
existing docs:
- New findings: NimbleBrain skill:// resource consolidation, skill
reliability/adherence issues across implementations
- Expanded approaches with distribution/provenance considerations,
resources adoption insight, and domain-level discovery (.well-known)
- Expanded open questions on dependencies and distribution trust
- Added Cloudflare Agent Skills Discovery RFC and NimbleBrain
reference implementations to related work
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Remove trust note since its already mentioned in the doc separately
* Clarify attribution for community insights on skill dependencies in open questions
* Refine findings on model skill adherence and community workarounds
* Remove outdated comparison section and streamline evaluation insights in experimental findings
* Remove unnecessary blank line in experimental findings documentation
* Add SEP-2093 proposal to related work documentation
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
* Add docs-as-MCP-server and plugin/powers use cases
Add two new use cases from Clare Liguori and Luca Chang (AWS) shared
in Discord after the first IG meeting:
- Documentation as MCP Server (search_docs/fetch_doc pattern)
- Skills + MCP Server Plugins (one-click bundling of skills + servers)
Add related implementations and external resources (Strands, AWS MCP,
Kiro powers, llms.txt, AWS Agent SOPs).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Add link to mcpdoc and more context
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
