Coming back to this since the same shape of concern came up again from @viswabalaji -- I think it's worth a closer look at where the question is actually live, because most cases really do reduce to "server picks per skill" the way you said.

Looking at anthropics/skills, the choice splits three ways:

1. Archive-only. pdf -- forms.md drives the agent through python scripts/check_fillable_fields.py, python scripts/extract_form_field_info.py, etc. The skill doesn't function unless scripts are on disk and executable. Server picks archive, done.

2. Per-file-only. claude-api -- 33 KB SKILL.md tells the agent to detect the project's language and read only the matching subdir (9 lang subdirs total). Archive wastes 8/9. Server picks per-file, done.

3. Client-dependent. This is the case I want to focus on, because it's where the concern keeps coming up and "server picks per skill" doesn't reduce. Example: internal-comms -- 1.5 KB SKILL.md plus four ~3 KB example files (3p-updates.md, company-newsletter.md, faq-answers.md, general-comms.md). SKILL.md says "identify the comm type, load only the matching guideline." Same cold-path access pattern as claude-api, but ~11 KB total, no scripts, pure reference content. This shape is going to be common -- company playbooks, brand guidelines, style guides, FAQ packs, runbooks. Probably the bulk of what gets published over MCP.

For this kind of skill the format isn't determined by the content; it's determined by the client:

• A Claude-Code-style client -- filesystem-backed, code-execution sandbox, treats every skill as a directory at ~/.claude/skills/<name>/ -- prefers the archive in one shot. Even when no scripts are executed, the harness's mental model is "skill = directory on disk, model reads with bash", and N separate resources/read calls to populate that directory is N round trips of pure overhead. Same goes for Codex CLI, the claude.ai code-execution container, the Claude API container.
• A lightweight in-memory client -- thin chat UI, mobile app, browser-only -- prefers per-file. There's no disk to populate; it just reads SKILL.md, decides relevance, and dereferences the one ~3 KB guideline it actually needs. An 11 KB archive is wasted bytes when it ends up using 4.5 KB.
• A gateway / many-hop client -- MCP gateway across regions, or a host batching connections to many servers at session start -- prefers the archive. Per-file's round-trip cost dominates when latency is the bottleneck, even on small payloads.
• A caching-aggressive client might lean per-file -- individual files cache and dedupe across skills more cleanly than opaque archive blobs.

The skill author can't predict which of these the requestor is. For a registry-style server fronting public skills, the consumer distribution is unknown by construction.

"Servers SHOULD pick one" forces some fraction of consumers to pay the wrong cost. The cleanest resolution I can see: shared-name entries in the index describe one skill in alternative representations, and clients pick by materialization strategy. The URI namespace already supports it (pdf-processing.tar.gz and pdf-processing/SKILL.md resolve to the same pdf-processing/ virtual paths, per the SEP body itself) -- the only thing missing is the index-level dedupe rule. Equivalently a representations[] array per entry; more explicit, more invasive.

Worth nailing down either way -- goose r2's current parser would produce two cache entries with the same name and collide downstream in aggregated_mcp_skills. Right now it's underspecified, and the same question is going to keep coming back from anyone implementing a server that wants to serve a class-3 skill to mixed consumers.

Coming back to this since the same shape of concern came up again from @viswabalaji -- I think it's worth a closer look at where the question is actually live, because most cases really do reduce to "server picks per skill" the way you said.
...

Just for other reading: we're discussing this on Discord https://discord.com/channels/1358869848138059966/1464745826629976084/1508940124803829760

Sharing a PHP implementation of this SEP as a reference point (the SEP currently lists none, and the documented implementations so far are Python/TS):

• Server / SDK: [Schema][Server] Add Skills extension (io.modelcontextprotocol/skills) support php-sdk#372 adds io.modelcontextprotocol/skills to the official PHP MCP SDK. addSkillsFromDirectory() serves a directory of SKILL.md files (plus supporting files) as skill:// resources, enforces the final-segment ↔ frontmatter-name rule, and generates skill://index.json. Serving is covered by MCP Inspector stdio snapshot tests (resources/list, resources/read of a SKILL.md / a supporting file / the index).
• Consumer: [Mate] Add Symfony bridge skills anticipating the MCP Skills extension symfony/ai#2132 ships skills in the Symfony "Mate" MCP server, colocated with the tools they orchestrate (including a multi-file skill with references/).
• Findings write-up: docs(findings): PHP MCP SDK + Symfony AI Mate skills-as-resources experimental-ext-skills#95.

Two pieces of spec-text feedback surfaced while implementing the server side:

1. Resource name vs. frontmatter name (Resource Metadata). The section says the SKILL.md resource name SHOULD be the frontmatter name. The PHP SDK constrains MCP resource names to [a-zA-Z0-9_-]+, so a skill whose identity includes a path can't be represented in name. We satisfied the intent via title and kept the real name as the final URI segment (already guaranteed recoverable). Might be worth softening the SHOULD, or explicitly naming title as an acceptable carrier, so SDKs with constrained resource-name charsets stay conformant.
2. _meta namespace is unspecified. The SEP says servers MAY expose extra frontmatter via the resource _meta, but defines no key, so we had to choose one (io.modelcontextprotocol.skills/). This is a concrete interop point — two servers under different keys won't interoperate. Tracked in experimental-ext-skills#55; flagging here since it intersects the normative text.

Minor note for other SDK authors: an extension advertising an empty {} capability payload is easy to accidentally serialize as [] (we hit this in the PHP SDK). A one-line caution in the capability-declaration section could save the next
implementer some time.

For the open question of whether clients consume MCP skills: as of June 2026, Claude Code loads skills from the filesystem/plugins only and treats MCP resources as user-mention attachments rather than model-driven reads, so it can't currently consume MCP-served skills end-to-end. FastMCP 3.0 looks like the right consumer to validate the serving half against next.

@wachterjohannes

1. Resource name vs. frontmatter name (Resource Metadata). The section says the SKILL.md resource name SHOULD be the frontmatter name. The PHP SDK constrains MCP resource names to [a-zA-Z0-9_-]+, so a skill whose identity includes a path can't be represented in name. We satisfied the intent via title and kept the real name as the final URI segment (already guaranteed recoverable). Might be worth softening the SHOULD, or explicitly naming title as an acceptable carrier, so SDKs with constrained resource-name charsets stay conformant.

I'm not sure I follow, what exactly is the problem? The path shouldn't be in the name anyway, and the name is already constrained by the agent skills spec:

Max 64 characters. Lowercase letters, numbers, and hyphens only. Must not start or end with a hyphen.

_meta namespace is unspecified. The SEP says servers MAY expose extra frontmatter via the resource _meta, but defines no key, so we had to choose one (io.modelcontextprotocol.skills/). This is a concrete interop point — two servers under different keys won't interoperate. Tracked in experimental-ext-skills#55; flagging here since it intersects the normative text.

It is already specified on the sentence immediately following the quoted one:

Servers MAY expose additional frontmatter fields via the resource's _meta object. When _meta keys are used for skill resources, implementations SHOULD use the io.modelcontextprotocol.skills/ reverse-domain prefix.

Thanks @pja-ant — both fair, and you're right on the spec text in each case. Turns out neither is actually a spec issue; let me separate that from the SDK-side artifact.

1. Resource name. Agreed — the skill name charset ([a-z0-9-], ≤64, no leading/trailing hyphen) is a strict subset of the MCP resource-name charset, so "name SHOULD = frontmatter name" is satisfiable, and I'll withdraw the suggestion to soften the SHOULD. The friction was entirely on our side: our SDK registers every resource — including a skill's supporting files (references/SECURITY.md, …) — under a unique, schema-valid name key, and as your acme/billing/refunds + acme/support/refunds example shows, two skills can legitimately share the frontmatter name refunds. So we can't use the bare frontmatter name as the registry key without collisions; we derive a unique name from the URI path and keep the frontmatter name in title. That's an SDK registration detail, not a spec gap — identity is the URI regardless. No change implied for the SEP.

2. _meta prefix. You're right, it's specified — and our SDK independently picked exactly io.modelcontextprotocol.skills/, so we're already conformant (a nice corroboration of the recommended prefix). What I was reading is the working-group repo-local copy, experimental-ext-skills/docs/sep-draft-skills-extension.md, which ends that paragraph at "…via the resource's _meta object." and doesn't include the prefix sentence — so the PR and that working draft have drifted. Might be worth syncing the repo copy. I'll fix my findings note accordingly.

Thanks for the close read.

Major update: the skill://index.json has changed, moving away from the .well-known Agent Skills proposal. It's unclear what the future of the .well-known index is and decoupling allows us to have more freedom over the format (which we are now taking advantage of):

• Frontmatter is mirrored to the index
• Archives are optional, additional serving formats rather than servers having to choose files vs archive.