Skills Over MCP Working Group - August 11th 2026 Meeting Notes

[olaservo]

Repo: modelcontextprotocol/experimental-ext-skills
Discord: #skills-over-mcp-wg
SEP: SEP-2640 (Skills Extension) (V1 proposal, Extensions Track)
Context: Peter was out. The first half covered SEP-2640 status — the vote is the remaining gate, and David Soria Parra joined with his review comments and an invitation to present at the core-maintainer meeting the next day. The second half was live triage of the project board.

tldr;

• OpenAI has implemented the current extension as part of their plugins (an install-a-snapshot approach) — early adoption, and a good signal that the current state becomes V1.
• SEP-2640 goes to the core maintainers tomorrow and minor tweaks don't need to block the vote.
• The SEP PR was showing as too large to render as a diff on GitHub. The rationale moves to the extension repo (Aditya volunteered the PR); the spec PR keeps the normative semantics. Going forward the main MCP repo holds the guidelines, the extension repo holds the rationale.
• Advisory limits are coming: file size and file count limits in the spec, plus advisory size metadata, so that clients converge instead of each inventing their own caps (OpenAI's plugin version has starting limits defined but are open to iterate on this as the spec settles).
• Dynamic resource semantics should be explicit. Rather than omitting a resource or digest to imply "dynamic," mark the state explicitly (e.g., a digest value meaning "dynamic, cannot be computed") so omission isn't conflated with non-existence. The group will do a pass over the spec for this.
• Skills-spec (as opposed to skills-over-MCP) conversations move to the Agent Skills repo's GitHub Discussions. Cross-referencing / "primitive grouping" topics go to that group's upcoming reboot.

Attendees

Name	Organization
Ola Hungerford	Nordstrom / MCP Maintainer
Aditya Kumar	Glean
Haoyu Wang	Google
Oluwatobi Oyewole	(org TBD)
Ian Hoffman	Slack
David Soria Parra	Anthropic / MCP Lead Maintainer
Jonathan Hefner	Skills spec maintainer / MCP Maintainer

(Note: other attendees were present but didn't appear in the transcript - please leave a reply if you want to be added)

1. Status: waiting on the vote, with adoption already happening

Ola opened with the state of the extension. The main thing the group is waiting on is confirmation that the core maintainers will vote to accept it and thereby finalize a version. Meanwhile, as folks may have seen on Discord, OpenAI has implemented the current extension as part of their plugins, taking the approach of installing a snapshot of skills from a server. Early adoption of the draft is a good signal that the current state really is V1.

2. Spec stability

Haoyu asked whether major changes to the SEP are still expected, since his team is considering supporting it. Ola's read: no — Den's adversarial audit last week produced only a round of smaller tweaks, which points to the spec staying roughly as-is through the vote. After the last few cycles she's always hesitant to declare "this is it," but everything recently suggests it's going to be what it is. David later seconded this from his own realtime review (see section 4).

3. Roadmap: V1 plus what?

The roadmap right now is essentially "ship V1." Ola invited suggestions for anything else the group wants to iterate on over the next six months, ahead of a roadmap-themes review with core maintainers and working group leads happening tomorrow.

Aditya raised the caching comment on the PR and suggested adding caching to V1 rather than punting it. Ola agreed and will apply the change, although this is the kind of change that could happen post-acceptance. (This is the SEP's remaining caching open question: skills/list results already carry SEP-2549's ttlMs/cacheScope attributes as of protocol version 2026-07-28, but the spec text currently leaves open whether skills/get results do too — so closing it is consistent with how things already work in this version of the spec rather than new scope.)

Other gaps Ola named: reference implementations and a client guide. There was a host-application reference implementation for a previous version, but nothing yet against the current version outside the in-the-wild implementations. Tobi has been working on a live demonstration in VS Code. Real-world examples of what the extension looks like implemented in an actual client would help a lot, as would circling back to server authors who expressed interest earlier. The client implementation guide remains a follow-up that hasn't been worked on yet.

4. Getting to the vote

Ian asked how the extension actually becomes officially supported, and when it can be communicated as available. The process: core maintainers vote to accept the extension; once accepted, that's the thing being built on and it can be communicated out. Most review has happened asynchronously; the official vote is the gate.

David had looked through most of the proposal and found it for the most part fine, with small changes. He invited Ola to bring it to the core-maintainer meeting tomorrow, noting the caching tweak and similar items can land after the vote — extensions can be accepted with changes, and there will probably always be minor changes.

5. David's technical comments

Advisory limits on files. David is worried about unbounded reads and unbounded listings. Limits suck in that they constrain what you can do, but developers will eventually impose hard limits anyway — suggesting limits in the spec leads to uniformity, while staying silent leads to randomness where the lowest common denominator wins. OpenAI's plugin version has already unilaterally imposed limits on skill count and file size, which proves the point. Recommendation: put advisory file-size and file-count limits in the spec.

Size metadata. Skill files don't carry a size parameter, so a reader is potentially reading a stream forever (a fundamental HTTP problem). At-least-advisory size information would let clients set read budgets and change behavior based on expected file size to avoid overreads.

Explicit dynamic-resource semantics. David questioned the SEP's rule that a skill's resources array "MAY be omitted only when a skill's content is generated dynamically, such that stable digests cannot be published." His position: being explicit that a skill exists but is dynamic is better than implying it through omission, because omission conflates "dynamic" with "non-existent." Two years from now, someone reading a trace shouldn't have to consult the spec's omission semantics — keeping the entry in resources with a digest field carrying an explicit "dynamic, cannot be computed" marker is self-documenting. (And content length isn't a counterargument; these things compress perfectly.) Aditya walked through his reading of the adjacent mechanism — a skill absent from the skills/list listing can still be resolved via skills/get, which returns its entry with URIs and digests you then resources/read (the spec's unlisted-skill path) — and agreed the current phrasing could be clearer (e.g., "skills that may be omitted" rather than reading as applying to all resources). David will reread the section and revisit his earlier comment; in principle both prefer the explicit-state approach. The group agreed to do a pass to make the spec explicit about these semantics.

6. Board triage and housekeeping

Tobi raised that the Kanban board has accumulated tasks that may no longer be relevant given the SEP's evolution, and offered his triage pass as a starting point. Ola agreed the board needs a reset to match the current state of the project and did a live cleanup:

• Progressive discovery (the alternative proposal PR) came out of review — per the roadmap, how to handle progressive discovery will be discussed separately from how skills get served over MCP.
• Glossary of terms went to review — several people have opened PRs; the plan is to mash a couple together and merge.
• Experimental findings stays open — once there are more implementations of the current version, the repo keeps taking PRs that snapshot real implementations, with the emphasis on actually reviewing them. A new issue will track example implementations.
• Script execution was addressed in the SEP; a comment will be added to the open question noting how.
• Resource templates went to backlog — V1 ended up not supporting them, and with skills/list in place they may not be needed at all. Sam (GitHub) originally raised this, so it may belong on a future roadmap discussion; Aditya will follow up on whether anything referencing resource templates is still necessary.
• Well-known discovery came out — the extension ended up not mapping one-to-one with the well-known proposal.
• Skill access control (an April question about gating the body of a skill so it isn't served automatically): the likely answer is omitting the skill from skills/list/skills/get and enforcing ACL checks on the resources, but a documented recommendation is owed on that thread.
• Drive-by questions tied to the current SEP went to Ready so they stay visible for anyone following those issues; overly vague items will be replaced by fresh issues.

On logistics: issues can't be assigned to people outside the repo's group, so Ola will add regular contributors to a members role so they can be assigned work and move cards. New issues will be created for topics discussed today that aren't tracked yet, including candidates for the formal roadmap discussion.

7. Where do skills-spec conversations go?

Several recurring topics (e.g., skill dependency declaration, expected execution environment in frontmatter) are really skills spec problems, not skills-over-MCP problems. The group has been a useful venue for general skills discussion, but Ola doesn't want the meeting to become skills office hours. Jonathan suggested the GitHub Discussions forum on the Agent Skills repo — he monitors and responds there — and noted a centralized, scannable collection of issues helps since the forum can be hard to sift. Someone rounding up the spec discussions the group wants to continue and seeding them as discussion threads there would be helpful.

Relatedly, cross-referencing between skills and tools ("first read Jira, then go do this in Salesforce") keeps coming up, especially from enterprises with skills spanning multiple servers.

Next steps

• [Ola or Peter] Update caching: Apply the caching change to the spec after final confirmation from David.
• [Ola] Present to core maintainers: Bring SEP-2640 to the core-maintainer meeting tomorrow (Aug 12).
• [DONE] Split the spec PR: Slim the PR down so the diff renders, removing the rationale section once it lands in the extension repo.
• [DONE] Move the rationale: PR the rationale into the extension repo.
• [PR Open] Grant repo access: Add active contributors to the repo group / members role so they can be assigned issues and manage the project board.
• [Aditya + Tobi + Ola] Triage issues: Continue removing irrelevant or stale tasks from the project board. (Will continue this on Discord)
• [Aditya] Resource templates: Follow up on whether anything still needs resource templates.
• [Ola + others] Create new issues: File tracking issues for today's topics that aren't represented on the board, including V1-roadmap candidates. (Will continue this on Discord)
• [Open] Skill access control: Post a documented recommendation (omit from skills/list + ACL on resources) on the original thread.
• [Open] Round up skills-spec topics: Collect the skills-spec discussions the group wants to continue and post them to the Agent Skills repo's GitHub Discussions.

---

Questions or follow-ups? Join us in #skills-over-mcp-wg on Discord.

Prepared from an auto-generated meeting transcript; please reply with any corrections.