Skills Over MCP Interest Group - Feb 26th 2026 Office Hours Notes

[olaservo]

Repo: modelcontextprotocol/experimental-ext-skills Discord: #skills-over-mcp-ig

---

⚠️ Transcript and Gemini did not record this time — notes from memory, so please correct or add if needed.

Attendees: Peter Alexander (Anthropic/MCP Core Maintainer, Ola Hungerford (Nordstrom), Luca Chang (AWS), Clare Liguori (AWS), Eliot Roe (Validin), Nate Moore (Zapier), James Baldwin (Zapier), Sunish Sheth (Databricks), and at least one other person from Zapier I whose name I can't remember :/

1. Skills as Resources: PR #16 and Next Steps

Peter, Ola, Luca, and others discussed the intent of PR #16 (Skills as Resources reference implementation) and what we would want to do next for exposing skills as resources.

The core question was whether the reference implementation should demonstrate: (a) how servers can expose skills to clients in today's ecosystem (workarounds and all), or (b) how we'd ideally want it to work as a proper extension/SEP.

Key points from the PR discussion:

• Peter suggested that rather than having each server ship its own load_skill tool, clients should support model-driven resource loading directly — e.g., a built-in read_resource tool on the client side and a SDK-level list_skill_uris() method. He argued it's a small lift for clients (compared to something like elicitation or sampling) and would avoid duplicate approaches or increased compatibility matrices.
• Luca noted that most clients today don't expose resource-loading to the model, so server authors currently can't rely on resources alone. However, he acknowledged Peter's point about the ideal direction.
• Ola proposed thinking about the repo as containing three things: (1) server implementation — how skills should be made available as resources, (2) client implementation — what client tools should be available to consume skills as resources, and (3) examples of server-side workarounds for clients that don't yet support (2). Peter agreed that ideally we'd focus on (1) and (2), and only include (3) if there were strong arguments for why resource reads are genuinely challenging for some clients.

This tied into a broader discussion about how clients and models today don't use resources consistently:

• Luca and others noted that resources are explicitly application-controlled in the spec, which means the model doesn't interact with them directly unless the client facilitates it
• Ola pointed out that resources are such a general primitive, that part of the lack of adoption is that it's hard for many to see the value without a concrete use case driving it
• Nate mentioned using a special hinting tool to help remind the model to load skills — a workaround for the model not proactively reaching for resources on its own

Conclusion: Lets focus more on the skills-as-resources approach using client helper tools up front. This will include experimental SDK changes to allow clients and models to load skill resources more consistently — which could also help open up other Resource use cases beyond skills. The plan is to partner with a few client implementors to test once we have the extension ready.

The other experimental "workaround" implementations (e.g., cramming the skills list into tool descriptions) still have value to demonstrate creative ways to achieve the same results. They can remain in the repo but should be more clearly separated in intent — serving as a comparison baseline when evaluating the resources-based approach in real clients.

2. GitHub as a Distribution Mechanism for Skills

Discussion on whether GitHub is a robust enough solution as a source for distributing and installing skills or plugins, especially in enterprise environments.

• Clare noted that Terraform went a long while without using a formal registry
• If you're using git, you can still point to tags and specific versions of git-based dependencies instead of just pulling in the latest files from a repo — versioned distribution doesn't strictly require a registry

3. MCPB for Bundling Servers + Skills

Both Ola and Eliot have been experimenting with MCPB for bundling both an MCP server and skills together as an alternative to the plugin model. (MCPB provides a way to define a bundle manifest that packages an MCP server config alongside skill files.) This is relevant to the broader question of how skills get distributed alongside the servers they complement — rather than requiring separate install paths (as with e.g. chrome-devtools-mcp's skills/ folder), MCPB could package them as a single artifact.

4. FastMCP Skills Provider

Discussion on whether anyone has tested using the FastMCP 3.0 skills provider yet.

• Luca has tested it, but noted it's a fairly similar solution to how skills.sh aggregates local skills files from different provider directories
• Ola noted a key difference in the update model: FastMCP supports more of a "pull" model for updating resources that have changed, while the implementation in the IG repo (PR #16) watches for changes and allows clients to subscribe to resources that have changed (via resources/subscribe and resources/updated notifications) — more of a "push" model
• Worth evaluating both models as the group considers what to recommend, but is probably use case specific

5. Multi-Server Skills and Dependency Configuration

Discussion on how skills can be useful in multi-server/tool workflows — a skill might orchestrate tools from several different servers. They can also make it more natural to translate ad-hoc tool-call-based workflows to scripted workflows, without fundamentally changing the content of the skill (by translating direct MCP tool calls to executed scripts or code.)

However, Sunish and others noted that the lack of explicit dependency configuration makes this unpredictable: if you don't already have the required servers and tools loaded, the skill can't reliably execute.

Related issue in the Agent Skills repo: agentskills/agentskills#110 — discusses how skills should declare their tool/server dependencies.

6. Skills/Resources Discovery Over MCP

Discussion on how someone could discover what skills (or other resources) are available on a server:

• The MCP registry doesn't currently expose what tools and/or resources are available in server.json
• Assumption is that this is being discussed as part of the Server Card work rather than the registry itself
• Action item: Need to catch up on the latest status of the server card + server.json relationship going forward

7. Repo Process: Using Issues for Tracking

To help others know where they can jump in to help, we'll start using GitHub Issues in the repo to track ideas and follow-ups. If anyone who wants to grab an issue isn't officially in the GitHub IG group yet, we can add them. Feel free to open issues too, especially for anything that comes up outside of meetings.