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

Date: April 7, 2026
Attendees: Ola Hungerford, Peter Alexander, Jonathan Hefner, Jack Tysoe (new participant - MCP Gateway @ Kong)

Discussion Topics

(Spoiler alert: several of the topics covered here were tangential to the main focus of the IG, but hopefully relevant tangents.)

1. CLIs and MCP — Dev Summit Recap

The group briefly recapped the MCP Dev Summit from the prior week. Lots of CLI discussion and "MCP is dead" memes. Jonathan shared a side experiment using Just Bash (from Vercel) to expose MCP tools as CLI commands, allowing an LLM to process results with standard bash utilities (head, grep, jq, etc.). Related to a project by Kurtis that served skills via tools with code execution. The group acknowledged the CLI naming debate (CTL vs. cuttle) and moved on.

2. Server Notifications and TTL Mechanism

Jack raised the difficulty of propagating server notifications in a gateway context — when multiple backends are involved, the gateway becomes responsible for signaling changes, which alters the protocol dynamics. He's been experimenting with a change-set ID / hash mechanism so clients can pull updates as well as receive push notifications.

Peter shared that the Transports Working Group is considering moving to a TTL (time-to-live) mechanism for tools list and resource list changes in the next spec. Clients would cache data for the TTL duration and pull fresh data after expiry. List-change notifications may become "best effort." There's also a separate Events and Triggers Working Group working on more robust server-to-client notifications, likely starting as an extension.

For skills specifically, if the resources approach is used, skills would naturally tie into resource TTLs and update mechanisms.

3. Model Access to Resources / read_resource Tool

A key barrier to the resources approach is that many clients don't give models direct access to resources. Ola noted this is a primary objection she hears from people who don't want to use resources — if the model can't decide to use it, it limits the value. Part of the current work is establishing a read_resource client tool so models can access resources directly.

Peter submitted a PR to the MCP spec proposing that clients should allow the model to read resources. The general impression from conversations at the dev summit was that people think the model should have access.

Ola shared her interpretation that "application-controlled" doesn't mean the model can't access resources — it means a resource is a way to reference data, and the application decides what to expose. A tool to fetch the resource remains viable.

Jack raised a practical concern: transparently replacing resources with search/get tools can lose context about the original request, and having the model semantically pick from a giant list is expensive. Chicken-and-egg problem around discovery vs. context window cost.

4. Well-Known URIs and Discovery

Jonathan updated on the well-known URI work for the Agent Skills discovery mechanism. This will serve as the basis for the manifest in skills over MCP.

Key developments:

• Internal implementation: Peter mentioned that he had experimentally implemented the well-known URI, only internally for now.
• Vercel/Mintlify support: npx skills add <domain> already pulls skills from the well-known URI. Mintlify auto-generates skill files from documentation sites (e.g., model context protocol.io already has a generated one). Jonathan has asked Mintlify to add a feature for hosting custom skills at the well-known URI path.
• Ad hoc plugin composition: Jonathan proposed using the marketplace.json plugin file with a type: "well-known" entry. A single domain could host both a well-known URI for skills and a well-known URI for an MCP server, and a client could install both from that one domain. This extends to future well-known URI types (agent definitions, etc.).

5. End-to-End Discovery Path Mapping

Ola emphasized the need to fully map out the end-to-end discovery path — how does discovery actually work from domain resolution through configuration to runtime loading? This would clarify how well-known URIs combine with skills-over-MCP and help with integration. Planned as a deliverable before the next meeting.

Using the MCP docs site (modelcontextprotocol.io) as a dog-fooding example was discussed. Currently Mintlify controls the well-known URI for that domain, so hosting custom MCP skills there would require either Mintlify adding that feature or using a separate subdomain.

Link to Mintlify-generated SKILL.md at well-known URI: https://modelcontextprotocol.io/.well-known/agent-skills/mcp/SKILL.md

6. Subdomains for Grouping and Trust

The group explored using subdomains as a grouping/authority mechanism for skill bundles, which is RFC-compliant with the well-known URI spec (well-known URIs must be at the domain root per the RFC).

• Each subdomain acts as a trust boundary / authority for its set of skills
• Jonathan proposed an orthogonal well-known URI for subdomain discovery — client hits the root domain first, gets a list of subdomains, then cascades to each subdomain's skill index
• Jack raised this from a multi-tenant perspective at Kong — "how would they operate this without one giant tool bundle?"
• Jack volunteered to investigate the subdomain discovery mechanism further

7. _meta Field Scoping for Skill Resources

Ola updated PR #60 (recommended _meta keys for skill resources). After community feedback (including from Jonathan), she scoped it down significantly:

"I was kind of taking all the things that were in the skills frontmatter and just saying like, here, put it in meta too so it's convenient... and I think people convinced me — is there a reason to do that? Are we just doing it because we can?" — Ola Hungerford

The revised position: only include metadata in _meta if it has a clear MCP-transport-specific purpose. Skill-level semantics (version, invocation, allowed-tools) belong in frontmatter.

Jonathan noted that if you do want metadata in the index, the main useful fields would be name, description, and possibly compatibility. Peter pointed out that since the discovery model is moving to index.json rather than resources/list, the _meta field is less important — you're not getting resource metadata from resources/list anymore.

8. Compatibility Field Discussion

Jonathan discussed the compatibility field in the Agent Skills spec. Currently there's an advisory that "most skills don't need a compatibility field," added to keep things simple. This may have been too optimistic — the field could address several practical problems. It's freeform text so clients would likely need to use an LLM to interpret it. If the field becomes more important, it might be worth including in index.json in the future.

Jack suggested tags or ACLs might be useful in the index. Jonathan agreed that ACLs belong at the distribution layer, not in the skill file itself, but groups/tags in the index for subset selection could be valuable. Keeping the first iteration simple to get alignment was the priority.

9. Sessions Removal from MCP

Peter revealed that the MCP core maintainers have accepted his proposal to remove sessions entirely from MCP. This was voted on and approved.

Motivation:

• Moving toward a stateless protocol — everything in every message
• Fixing elicitation and sampling to also be stateless
• No client implements sessions as expected — ChatGPT creates a new session on every tool call, Claude did the same until recently, most scope sessions to the application rather than per-chat-thread
• Some use it for telemetry (QPS per session) but that's better served by user ID or auth context

Proposed state management model: State through tool calls. Stateful applications would expose a create_session tool, and the model passes the resulting session ID into subsequent tool calls. Peter ran evals to validate this:

"Even with multiple resources and hundreds of operations, Haiku is just saturating it 100%, no issues. So I'm not too worried about it... I'm still trying to find a way to break it." — Peter Alexander

Concerns raised:

• Some gateways use session IDs to route/spawn stdio servers on the backend (process-level state isolation)
• Mutable tools lists scoped to sessions (e.g., enabling admin tools) would no longer be possible
• Peter's counter: no client actually handles session-scoped tool lists correctly, and the TTL mechanism will make tools lists stable per-application

Jack agreed from the Kong perspective — they could handle sessions through their own built-in subsystem, and the protocol-level session was mostly unused.

10. Claude Code Implementation Plans

Peter is working on getting an initial experimental set of skills implemented in Claude Code for internal testing. Plan: internal users first, then launch as an experimental feature, gather feedback, then develop a proper extension.

11. Resource Templates and Static Index (Late Discussion)

In the tail of the meeting, Jack asked whether the skills extension RFC includes search functionality or just a static index. Peter confirmed it's a static index. Resource templates will be supported — primarily because GitHub wants them for dynamic skill discovery across repos — but Peter doesn't expect many others to use them. The skill://index.json resource is the primary discovery mechanism.

New Action Items

To be added to issues in the project board for tracking: