* docs: sync SEP copy with upstream commit b405ba5
Re-syncs docs/sep-draft-skills-extension.md from the canonical
sep/skills-extension branch (twelve commits, 2026-08-11 to 2026-08-21)
and updates the pinned commit reference in the header.
Most of the removed lines are the Rationale section, which upstream
replaced with a pointer to docs/rationale.md in this repo. That text is
not lost, it now lives in one place instead of two.
The rest: per-skill limits and a `size` field, an explicit "dynamic"
marker in place of the omit-`resources` rule, (server, URI) as a skill's
identity, on-demand retrieval with write-isolated caches, the window in
which a host is acting on a skill, and `resultType` on every sample
result.
* docs: update rationale for the SEP sync
Three passages said dynamically generated skills omit `resources`, which
is no longer valid, and the per-file-digests section offered "cache the
whole set at approval time" as the pinning primitive, which the SEP now
forbids.
Adds a section on why an enclosing skill's manifest includes its nested
skills, recording the answer given on the concerns doc: content-bound
approval binds to the `resources` set, so the set has to be complete.
* docs: re-sync SEP copy to upstream commit 753b9f2
Picks up the table reformatting from 753b9f2 and updates the pinned
commit in the file header. No specification text changed between
b405ba5 and 753b9f2.
* docs: record why hosts retrieve skill files on demand
The SEP prohibits fetching a skill's files ahead of need but explains
it in one sentence, and the reasoning for the cache-integrity rule that
accompanies it is only in the upstream commit messages.
Add a rationale section covering the server-load argument, why lazy
retrieval leaves content-bound approval intact, and what it gives up
relative to staging the whole resources set at approval time.
* docs: tighten the on-demand retrieval rationale
Merges the two paragraphs that both argued late retrieval is still safe,
and drops the restatement of the cache mechanics -- write-isolation,
re-hashing on access, digest labels not counting as verification -- which
Security Implications owns. The rationale needs the shape of the trade,
not a second copy of the rules.
Also corrects the limits sentence. 512 files and 16 MiB are host-support
floors, not a cap on what a server may serve: a skill above them is not
invalid, it just loses guaranteed portability.
Drops the threat-model link. The rotation point it supported is correct,
but the document still names `install` its recommended baseline and
argues for immutability on the grounds that there is "no second live read
to diverge" -- the model this section prohibits. Restore the link after
the threat model is revised.
* docs: trim the on-demand retrieval rationale
Server load is one reason for retrieving late, not the only one. The paragraph on what late retrieval gives up restated verification rules the spec already carries.
Re-syncs docs/sep-draft-skills-extension.md from the canonical
sep/skills-extension branch (Apply suggestions from code review,
2026-08-05) and updates the pinned commit reference in the header.
* 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 working draft's Resource Metadata section omitted the sentence
recommending the io.modelcontextprotocol.skills/ prefix for _meta keys,
which is present in the submitted SEP-2640. Bring the repo-local copy
back in line with the PR.
* 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>
* Add draft SEP for Skills Extension
Pre-submission Extensions Track SEP defining the skill:// resource
convention: skills as MCP resources following the Agent Skills spec,
discovered via scoped resources/list (SEP-2093). Includes implementation
guidelines for host-provided read_resource tools, virtual-filesystem
unification with local skills, and SDK convenience wrappers.
* Relax URI structure and make discovery optional
- skill-path may be arbitrarily nested and need not match the
frontmatter name; the URI is a locator, identity lives in SKILL.md
- resources/list(uri="skill://") is SHOULD not MUST; response is
SKILL.md entries only, supporting files excluded
- resource templates are MAY, framed as user-facing (completion API)
- direct URI readability is the baseline; hosts must support loading
skills they have never seen listed
- SEP-2093 dependency is now conditional on whether the server
supports enumeration
* Constrain final path segment to match frontmatter name
The previous draft fully decoupled <skill-path> from the skill name,
which meant the name could not be read from the URI without fetching
and parsing SKILL.md.
Now: the final segment of <skill-path> MUST equal the frontmatter
name. Preceding segments remain an optional server-chosen prefix for
organizational hierarchy. This keeps the hierarchy capability while
making the skill name recoverable from the URI alone.
* Replace scoped resources/list enumeration with skill://index.json
Enumeration now uses a well-known skill://index.json resource whose
format mirrors the Agent Skills .well-known discovery index: same
$schema, same skills[] shape. Two deltas from the HTTP index: url
holds the full skill:// URI, and digest is omitted (transport handles
integrity over an authenticated connection). type MUST be "skill-md"
since archives don't apply when every file is individually
addressable.
This drops the SEP-2093 dependency entirely — the extension now has
zero protocol dependencies beyond resources/read.
Also includes review feedback from PR #69:
- Security: skill content MUST be treated as untrusted input; hosts
MUST NOT honor local-execution mechanisms (hooks, scripts) without
explicit opt-in; "more harm" softened to "as much harm"; user
inspection SHOULD be supported
- Cite agentskills.io parent-directory rule for the final-segment
constraint
- No-nesting constraint reworded per cliffhall suggestion
- Abstract mentions progressive disclosure as delegated concern
- Hosts section: SHOULD load frontmatter into context, SHOULD surface
skills for user enable/disable
- read_resource signature marked illustrative
- "community has explicitly pushed back" softened
* Relax skill:// scheme to SHOULD; add urlTemplate to index
The index is now the authoritative record of which resources are
skills, so the scheme prefix is no longer required for identification.
Servers SHOULD use skill:// but MAY serve skills under a
domain-native scheme (github://, etc.) provided they're listed in
skill://index.json. Structural constraints (final segment = name,
explicit SKILL.md, no nesting) apply regardless of scheme.
Index entries now carry exactly one of url or urlTemplate. type stays
"skill-md" either way — it describes what the resolved URL points to,
not whether the entry is parameterized. Template entries omit name.
Servers SHOULD register the same urlTemplate as an MCP resource
template so the completion API works.
The Resource Templates subsection is deleted; templates are now an
index feature (a "template entry") rather than a parallel discovery
mechanism. Discovery is down to two mechanisms: the index and server
instructions.
skill://index.json remains the one fixed URI.
* Use type:"mcp-resource-template" for template index entries
Template entries now reuse the url field with type as the
discriminator, rather than a separate urlTemplate field. This is
consistent with the upstream schema where type already discriminates
how to interpret url (skill-md vs archive). The mcp-resource-template
type is namespaced so upstream consumers skip it safely per the
existing unrecognized-type rule.
Ola Hungerford
Johannes Wachter
Peter Alexander