Skills Over MCP Working Group - July 28th 2026 Meeting Notes

[olaservo]

Repo: modelcontextprotocol/experimental-ext-skills

Discord: #skills-over-mcp-wg

SEP: SEP-2640 (Skills Extension) (V1 proposal, Extensions Track)

Context: Held on the day of the 2026-07-28 spec release. Peter was out. The agenda was catching everyone up on the scoped-down SEP-2640 revision now waiting on core-maintainer feedback; the rest of the hour was attendee questions from people implementing against the draft.

Two docs merged right after this session: threat-model.md (PR 108) covers T1 through T9, mapped to the dangerous-skills-mcp corpus and to SEP clauses. decisions.md (PR 110) now consolidates the July rework into a single ADR, which is the best place to start if you want to know what changed.

tldr;

• SKILL.md is the entry point. Supporting files are sibling resources, each with its own SHA-256 digest. There is no aggregate digest. skills/get is the cheap single-skill refresh, added at Aditya's request in SEP review.
• Archives stay out, recorded as a deferred feature with the objections that removed them.
• The threat model recommends install (verify up front, write to a host-private immutable store) over load-on-demand. It is a WG reference rather than SEP text, and it differs from where most prototyping has gone.
• A client guide will live outside the spec.
• Enterprise governance is a recurring topic and motivator. Server-side access control over skills is why several interested parties want this.
• Still open, out of V1: what a client does with skill content it already holds after a user's entitlement changes.

Attendees

Name	Organization
Ola Hungerford	Nordstrom / MCP Maintainer
Nate Barbettini	Arcade.dev
Samuel Kantor	Slack
Sruly Rosenblat	AI Disclosures Project
Aditya Kumar	Glean
Ian Hoffman	Slack
Vijaydeep Sinha	Adobe
Arsham Mesbah	Microsoft
Jonathan Hefner	Skills spec maintainer / MCP Maintainer

---

1. Entry point and ingestion patterns

Vijaydeep asked what a client reads first when a skill is a directory of files. The answer is SKILL.md, always. Relative references inside the skill resolve against its root exactly as on a filesystem, and there is no dependency graph to resolve: the entry gives you URIs and digests, and you read what you need.

Ola recapped the two ingestion patterns the group has discussed before. A host can install what the server serves and treat it like ordinary file-based skills, or it can discover and pull resources on demand. Server-side reads can be identical, but the host-side consequences are not. Her read of the field was that on-demand is what almost everyone has prototyped, since many clients already have tools letting the model read arbitrary resources.

Update. The merged threat model recommends install as the baseline: fetch up front, verify each file against the resources digest set, and write to a host-private location outside any path exposed to MCP tools or the model's execution environment, held immutable. Verification then happens once over the whole pinned set, and immutability removes the window that content rotation and live-read divergence exploit. load-on-demand stays supported, but it must re-verify on every read and reject any URI not in resources. The recommended shape and the commonly built shape are different, and the threat model's position is that on-demand is easier to reach with existing client tooling, not that it is safer.

2. Digests and caching

Vijaydeep asked for a root-level digest so a client can detect change without walking every file. There isn't one. resources carries one SHA-256 per file, and the cheap-refresh path is skills/get, which returns a single skill's current entry without re-enumerating the catalog. Aditya noted that a top-level digest was part of why the group wanted archives, which were removed.

Ola restated the scoping principle: V1 is the smallest functional version, deliberately excluding anything that reopens security or distribution questions.

3. Verifying that a resource belongs to a skill

Samuel asked about a case several servers hit. They serve a SKILL.md plus related markdown in the same directory, so when a client reads one of those files, is directory membership enough, or must it validate against the entry from skills/get? Ian proposed the minimal answer: treat them as arbitrary reads, verify with digests if you want, and let membership be a semantic detail the model works out.

Correction. The current draft is stricter than the discussion suggested, and the merged threat model (T4) confirms it. When present, resources MUST be complete, listing every file exactly once.¹ A host MUST verify each retrieved file against its digest, MUST resolve reads of that skill's files only to URIs in the entry, and MUST treat a read of an unlisted file inside the skill as a verification failure.² Samuel's instinct is what the spec requires: directory membership is not sufficient, and the entry is authoritative wherever a host holds one.³ This closes what the threat model calls the B1 gap, where a digest covering SKILL.md alone left supporting files rotatable under a still-valid approval. adv-supporting-file-digest-swap is the runnable case.

Related: the draft now permits nested skills. A nested SKILL.md read as supporting content is ordinary markdown, so hosts must not act on its frontmatter, and activating it as a skill needs fresh consent. That is T9, with no corpus fixture yet.

4. Versioning, the client guide, and what the spec doesn't define

Ian noted that a host does not learn whether related resources changed until it reads them, which works but puts more on clients. Arsham gave the concrete case: a server ingesting skills dynamically from a store or git remote, where digests change between calls. Jonathan confirmed nothing definitive on skills versioning elsewhere.

Ola's answer is a client guide outside the spec, covering ergonomic patterns without making the spec unreadable. She also noted that custom frontmatter now passes through verbatim, which is what people already use for version and constraint metadata.

Sruly asked whether a server could scope a large catalog to the directory a client is working in. Ola put that on the host side, along with activation, installation, and caching strategy. One correction to that framing: the spec is not silent on caching. See section 6.

5. Enterprise governance and the skills side channel

The question underneath much of this session: customers want skills over MCP so they can govern them, where everyone connects but not everyone gets every skill. That is harder to guarantee when the client's answer is to write markdown to disk. The ask is to be able to tell clients they may persist skills only after checking the server, or not at all.

Core maintainers have raised the same thing, since leaving it open-ended gives server authors no clear expectation of client behavior. Aditya added that customers want to allowlist which servers may distribute skills, and asked whether a server-level signature or top-level digest would help. The counter-view from the room was that the absolute URI is enough, since managed client settings already restrict which MCP server URLs a client may connect to. What that cannot close today is the skills path, where anyone can point a client at some markdown file. Views also differed on which surface is more sensitive — some customers treat tools that way because they take destructive actions, others see skills as carrying the process knowledge — but there was agreement on the governance need either way.

Ola agreed the follow-up is being more opinionated about default client behavior, since what matters in practice is whether the large clients implement something hardenable. She flagged the two host shapes having different constraints: local agents that can already do arbitrary things, and web-based clients that cannot. Nate added mobile clients to that second group, along with a push back on treating the coding-agent shape as primary: in much of the enterprise world it is only the locked-down web and mobile clients.

From the threat model. Aditya's impersonation concern is now T8. Because name is a label and not an identifier, a server can publish under a popular skill's name, and the defense is per-origin namespacing with host-assigned server labels. Separately, confidentiality of the catalog itself, meaning what name and description leak about internal process, is explicitly out of scope as a host-deployment concern. If that is a live requirement for anyone, it needs its own thread.

6. Caching and revocation

Arsham asked where the gap is, given MCP's existing authorization story. The answer from the room was that all of it already works, and that no change to the security model was being proposed — governance living on the server is the model enterprises like. The narrower question was whether this extension has an opinion about what a client may do with what it retrieved, by analogy to a shared Drive file, where access revoked later does not remove the copy already on disk. The scenario offered: a user moves from finance to engineering, the next skills/list reflects the new role, so what should happen on the client? Arsham's follow-up sharpened it — do the previously downloaded skills get deleted automatically, without the user saying anything, and is that acceptable? Ola compared it to a git clone you can no longer update, and floated a governance group for this class of problem. The counterpoint was that unlike a git clone, the group hypothetically could set strict client requirements here. There was agreement that it is out of scope for V1.

Narrowing the open item. The spec already covers more of this than the discussion assumed. Persisted approval MUST bind to the resources set at approval time, and is revoked when a later entry differs. Cached content MUST stay out of every filesystem-skill discovery path and MUST keep counting as MCP-origin after restart and after disconnect, and it SHOULD be removed when the user removes the server (T7). What remains unaddressed is the entitlement-change case, where content is unchanged and access is withdrawn. The threat model does not cover it either, since it sits outside that document's scope. Recording it in those terms should keep it from being re-argued as a caching question.

7. Prototypes and timeline

Still targeting a finalized spec within a month, with the caveat that scope is whatever the core maintainers decide makes sense for this round. Other spec priorities needing attention been the main recent challenge, and now that the spec release has passed we expect more bandwidth for extension feedback.

No merged open-source IDE or coding-agent client has been released yet. PRs were opened early on, but the design kept moving so they still need to get updated. fast-agent exists as a prototype, though it is an agent library and not an IDE. On the server side the examples are either simple example servers or deliberately malicious ones, with little tied to the working group in between. This is a gap that the group can help to fill in the coming weeks.

Next steps

• Client guide. [Ola and/or other contributors] The threat model's install recommendation and host obligations cover the installation half; the guide covers the ergonomics it does not.
• Decide if the consumption default goes normative. install is recommended as a WG reference. Whether that moves into the SEP or stays advisory is an open call.
• Corpus additions. Four threats have no fixture yet in the dangerous skills MCP fixtures: cross-origin name collision (T8), directory-walk escape (T5), nested-skill consent (T9), enumeration exhaustion (T6).
• PR #831 follow-ups. file: and non-skill:// URLs, fetch-layer size caps, per-server fetch budget. Client-guide lesson: match on scheme, not string prefix.
• Scope the revocation question as entitlement change with unchanged content. Candidate for follow-on governance work.

Discord channel link for follow-ups and discussion: #skills-over-mcp-wg

---

Meeting notes prepared by Claude from an auto-generated Gemini transcript and manually edited.

Footnotes

1. resources MAY be omitted for dynamically generated skills whose content cannot be pre-digested. Such a skill has no content integrity and cannot be content-bound; hosts MAY decline to load it, and server authors should expect some will. ↩

2. The read-fencing rule applies while acting on a skill for which the host holds an entry. It does not require obtaining one — the baseline is that a URI alone is enough to read a skill, and skills/get is what turns a bare URI into a verifiable entry. ↩

3. Not raised in the session, but the same principle: after fetching a SKILL.md for which it holds an entry, a host MUST parse its YAML frontmatter and compare field-by-field against the entry's frontmatter, treating any discrepancy as a verification failure. The entry binds the metadata a user approved from the listing, not only the bytes. ↩