Skills Over MCP - Agentic AI Foundation (AAIF)
AGNTCon+MCPCon Europe • Sep 17-18 • Amsterdam • REGISTER NOW
Icon Close
span]:bg-coral-500 [&>span]:h-0.75 [&>span]:absolute [&>span]:rounded-full [&>span]:transition-transform [&>span]:duration-300">
Join AAIF
Skills Over MCP
Angie Jones<br>June 18, 2026
I’m a big fan and user of both MCP and Agent Skills, so when I learned there’s a Skills Over MCP working group (WG) that’s looking into integrating Skills with MCP, I had no choice but to lurk.<br>The problem<br>Think about any product you’ve ever used… software or not. Most come with some sort of instruction manual that helps you figure out how to use it.<br>For developer products, that’s usually in the form of docs, tutorials, examples, and maybe troubleshooting guides. Companies that do this well are often praised for their attention to Developer Experience.<br>But now we’re asking our agents to become users of products on our behalf. We give them an MCP server that essentially provides a list of tool names and descriptions and expect them to figure it out without flailing or messing up. This is horrible Agent Experience.<br>So, the working group is exploring how to go about providing instructional content to agents alongside related MCP servers.<br>Of course, Skills already solve the problem of teaching an agent how to do something in a way that avoids context bloat. The standard utilizes progressive disclosure techniques to help the agent find a given skill when it needs it without filling the context window with all of the nitty gritty details when it doesn’t.<br>This immediately made me think back to when the Playwright CLI dropped earlier this year. The CLI itself was hot, but the team also shipped a Playwright CLI skill. If you installed the CLI and the skill, your agent now had everything it needed to nail tasks without guessing about the shape and structure of the CLI’s commands and arguments. Which was amazing considering this was a brand new product and thus not in the LLM’s training data. This makes a very happy agent and therefore a very happy human as there are quicker sessions, fewer errors, and lower token spend.<br>But there still remained a bit of separation. The CLI and the skill need to be installed and maintained separately, as they are two different things. This isn’t exactly shipping the manual with the product.<br>So, the premise that the Skills Over MCP WG is exploring is what if we found a way to ship MCP servers with accompanying skills. That should give the agent the tools it needs to execute but also the operational knowledge it needs to do it efficiently. Essentially, ship the manual with the product.<br>The proposed solution<br>As opposed to adding yet another primitive to the protocol (which the WG did consider originally), they are looking to expose Skills as content through the existing Resources primitive. Resources are read-only pieces of data that lets the agents connect to external documents, databases, etc. They are essentially a read-only book that the agent can use to learn new facts. So, perfect for Skills!<br>The proposal is SEP-2640: Skills Extension with extension identifier:<br>io.modelcontextprotocol/skills<br>Given the shape of a Skill:
my-skill/<br>├── SKILL.md<br>├── scripts/<br>│ └── helper.py<br>├── references/<br>│ └── workflow.md<br>├── assets/<br>│ └── template.md<br>└── examples/<br>└── example.md
That Skill package could be served as a collection of resources using a skill:// URI scheme.
skill://my-skill/SKILL.md<br>skill://my-skill/scripts/helper.py<br>skill://my-skill/references/workflow.md<br>skill://my-skill/assets/template.md<br>skill://my-skill/examples/example.md
The great thing about this approach is that MCP doesn’t need to understand what a skill is. As far as the protocol is concerned, these are just resources. The skill format itself remains owned by the Agent Skills specification.<br>A server isn’t limited to exposing a single skill. It might expose dozens (or even hundreds) of them. For example, the Stripe MCP server could easily bundle the following skills
skill://subscription-management/SKILL.md<br>skill://refund-processing/SKILL.md<br>skill://payment-disputes/SKILL.md<br>skill://billing-investigation/SKILL.md
That immediately creates a discovery problem. We don’t want the agent reading every skill from every connected server just to figure out what’s available.<br>To solve that, the proposal defines a well-known resource as the server’s optional skill catalog:<br>skill://index.json<br>Rather than loading every SKILL.md, a host can read the index file and get lightweight metadata (e.g. name, description, location) about the available skills. This respects the discovery technique introduced by the Agent Skills spec.
"skills": [<br>"url": "skill://refund-processing/SKILL.md",<br>"frontmatter": {<br>"name": "refund-processing",<br>"description": "Use this skill when issuing refunds, handling partial refunds, or investigating refund status."<br>},<br>"url": "skill://payment-disputes/SKILL.md",<br>"frontmatter": {<br>"name":...