Repo: modelcontextprotocol/experimental-ext-skills

Discord: #skills-over-mcp-wg

Date: June 2, 2026

Attendees

1. Context: Bloomberg's MCP platform and what they've shipped

Sam set the stage: Bloomberg runs an internal MCP platform serving 10k+ engineers, providing both a managed server offering and common client integrations across many harnesses (deep agents, Claude Code, Codex, simple React loops, web apps). They have implemented and shipped the current skills-over-MCP SEP on both sides. Because they operate a managed server layer, format translation (archive vs. SKILL.md) and distribution can be handled centrally, and they've layered auth and rate limiting on top of skill gets. Skills are openly discoverable, but fetching protected reference data is authenticated.

2. Client compatibility filtering and where compatibility / frontmatter should live

With many different clients connecting to one index, the server or client needs to filter skills by what a given harness can actually use. Bloomberg's basic case: if a skill ships a scripts/ folder they assume a sandboxed execution environment is required and filter those skills out for harnesses that can't run them. The Agent Skills compatibility field is a freeform string today, meant to be handed to the agent to evaluate against its own environment; Bloomberg instead encodes structured key-value pairs in frontmatter metadata so a deterministic client-side filter can run over the index without fetching every skill.

The group discussed mirroring frontmatter into skill://index.json to avoid an N-fetch just to read front matter. Mirroring the entire frontmatter was previously rejected, but the compatibility field specifically was more appealing to mirror; skills spec maintainers had deferred it to keep the first version simple. Maintainers in the meeting were open to adding it but flagged the slippery slope (compatibility, then when-to-use, then everything) and the duplication / sync question (what happens when index and frontmatter disagree, plus YAML-vs-JSON concerns). A middle option raised: copy only a designated namespace of metadata keys into the index rather than the whole block. The sense was that this likely belongs in the Agent Skills spec and needs to be pushed forward there, with specifics deferred to async. Bloomberg also noted they use a separately-proposed variants extension for client/server capability negotiation as a stop-gap, but want platform-level filtering to work out of the box from skill-author labels rather than requiring servers to hand-write negotiation.

3. The core gap: resources have no "ls" or "grep"

Underneath most of the technical discussion: MCP resources lack filesystem vocabulary. There is no multi-resource get and no way to list resources under a path prefix. Sam's worked example — a skill whose reference data is generated per user profile (potentially hundreds of variants, hundreds of MB) where the agent should progressively load only the relevant template — works on a local filesystem (the agent can grep / list / navigate) but breaks over MCP, where you either read one file at a time or download the whole archive. The group agreed this is real but framed it as "would be nice if MCP also supported it" rather than a regression versus other skill transports. Everyone converged on wanting a filesystem-like abstraction (list + read over a subpath) eventually, while avoiding boiling the ocean (byte-offset reads, a full virtual FS) in a first cut.

4. Resource list: scoping a minimal V1

The main ask narrowed to a list keyed on path separators: given skill://skill-four/bar, return everything under bar/ (exact path, no prefix search needed). Peter noted he previously had a resource-list SEP (a resources/list taking a URI, paired with reading resources) that didn't converge on the exact API in time for the upcoming spec release, and floated whether a resource-template list (mirroring resource-template read) or completions would be sufficient. The group's sense: list alone would cover ~90% of the value and could ship inside the extension as a testing ground, with promotion to the core protocol later if it proves out. Sam suggested marking it as a standalone experimental capability so its lifecycle is independent of the skills extension; Peter leaned the other way — tying it to the extension so that a skills-capable server's support for resource-list is discoverable — but agreed to take the exact scoping to lead maintainers.

5. Archive vs. SKILL.md distribution: the dual-format debate

How should a server offer a skill both as an archive (one download) and as individually-addressable files (progressive discovery)? Three options surfaced:

• (a) Archive URL in index.json — expressed as a list of URIs on one entry rather than duplicate entries, to avoid repeating and reconciling name / description / compatibility.
• (b) An MCP-level naming convention — Bloomberg's shipped approach, where a skill at some path is also fetchable as <skill-name>.tgz alongside a real SKILL.md so they don't violate the spec.
• (c) A single resources/read returning multiple content blocks, one per file.

The group traced all three back to the same root cause — no multi-resource get — and agreed that if MCP had multi-resource get, neither the tarball nor the dual format would be needed. Provisional shape: SKILL.md as the required baseline, archive as an optional efficiency add-on. No syntax decision — agreement on the need, follow-up on form.

6. Rate limiting and why N reads is expensive

The group discussed why issuing ~1,000 resources/read calls at startup (e.g., 20 skills × 50 files) is actually a problem. Bloomberg rate-limits all MCP methods, so a bursty fetch-everything pattern gets throttled; beyond rate limits, each request carries CPU overhead server-side, whereas streaming bytes is IO-bound, and one archive blob can also cut total bytes. MCP has no streaming downloads — everything is blob-encoded — so an archive is the practical way to bulk-transfer today.

7. Reinstating the digest field

The per-entry digest had previously been stripped from skill://index.json: integrity doesn't apply over MCP (the same authenticated server serves both the index and the resources), and cache-freshness seemed better solved generally for resources. The group converged on putting it back. Caching is the driver: there's no general resource-freshness mechanism in the protocol yet (resource metadata came up only as a proposal), so the index digest is the client's only signal that cached skill content — which can run to tens of MB — is stale. Jonathan added a consistency argument: interdependent skills can shift underneath a client between the index read and sequential skill fetches, and a digest lets the client detect the race and retry. This also confirms the caching model generally: clients cache skills locally and refetch the index periodically, and the newer spec attaches a TTL to each resource to hint refresh cadence.

8. Resource templates: keep or kill?

The group leads floated removing resource templates. The discussion separated why user currently need them from whether they're worth keeping:

• Go SDK constraint. The Go MCP SDK requires declaring all resources up front, so templates are the only way to add resources dynamically (lazy-loaded or dynamically-discovered skills). Jonathan clarified that the base MCP spec lets a client read a resource by URI without it appearing in resources/list, so static pre-registration blowing up the list is a Go-SDK limitation, not a protocol one.
• Ongoing usefulness. Independent of the SDK, templates let you find / add skills without refetching the index, and enable completion-driven discovery — Peter described the Claude Code flow (/mcp → template autocomplete → completions → invoke the skill) that enumerates resources without listing them all. Ola's GitHub example (discovering skills by org / user / repo via a template, with the model running its own completion) works well.

Ola proposed checking back with the people who had asked about implementing them, to confirm their use cases still hold given a listing mechanism. The docx-skill case illustrated the remaining gap: a SKILL.md may reference only ~3 files while the directory holds ~50 (e.g., Python module files), and templates alone don't enumerate them — that's what resource list would solve.

9. One extension or several?

The group discussed whether the resource-list / filesystem proposals should be folded into the skills extension, since they're tied to the problem it's trying to solve, and voiced the worry that baked-in workarounds harden into the new status quo. One concern raised was that changing a core protocol thing inside the extension would draw much more scrutiny and risk delaying getting the skills extension out at all. The underlying framing: skills are just files, and resources are meant to represent entities like files — so if resources can't model files, that's a problem worth naming. Robert's take was that resources behave more like an object store (S3 — list exists, but not the full filesystem surface) than a literal filesystem, which helps calibrate how far to push the analogy.

10. Next steps

What's needed: some compatibility / frontmatter availability in the index, a way to expose both archives and individual files, a resource-list (with prefix / path) mechanism, and the digest added back. Peter will talk to lead maintainers about landing a minimal resource-list change and how it's expressed in the SDKs. Sam offered to walk the group through Bloomberg's full client- and server-side implementation in a future session. Remaining details to be worked async.

Post-meeting follow-up (Discord, #skills-over-mcp-wg)

Peter posted a summary of what to solve, with status converging over the following days:

1. digest — bring it back for caching / consistency. Done: digest is now back in the SEP.
2. Resource templates — leaning toward removal; wants more community input. Sam Morrow (GitHub) confirmed he's content to drop templates for now, on the grounds that landing the extension matters more, and flagged a security angle: arbitrary skill installation / invocation across all of GitHub via agents and resource templates is its own hazard, so dropping it avoids future end-user pain. (Sam also noted GitHub MCP may end up replacing server instructions with skills, echoing the May session.)
3. resources/list(uri) — try to get it into the protocol. At least one maintainer (dsp) is onboard, so the ball is in Peter's court to spec it out.
4. Archive + SKILL.md simultaneously — supported as a goal; exact mechanism still to be decided.
5. Frontmatter in the index — still to decide what needs to go in and in what form.

Thread for follow ups and discussion: https://discord.com/channels/1358869848138059966/1511425369637650482

Meeting notes prepared by Claude from a Gemini-generated transcript and manually edited