On August 26th, OpenAI shipped support for a new MCP extension, Skills Over MCP, in its plugins. I think this might be a big deal. I also think the timing is a mess. Both can be true.

I recorded a video breakdown of the whole thing. Watch it here or keep reading for the written version.

The four words you need

  1. MCP. The Model Context Protocol, an open standard for how an agent connects to outside systems. Anthropic started it in November 2024 with a local transport, it became the de facto standard for agentic tool calling by around April 2025, and Anthropic donated it to the Linux Foundation’s Agentic AI Foundation in December 2025. Virtually every harness now implements an MCP client.

  2. Tools. The actions an MCP server exposes. A named function with an input schema that the model can call: create_refund, list_orders. Tools are what the agent can do.

  3. Resources. The data a server exposes. Read-only content the client fetches by URI: a file, a record, a docs page. If tools are verbs, resources are nouns. Skills Over MCP is built entirely on this one. A very elegant choice in my opinion.

  4. Skills. A directory that teaches an agent a procedure. A SKILL.md with a name and description in its front matter, then markdown telling the agent how to do a job. There is an open standard for the format at agentskills.io. Skills are how to do the job.

Skills Over MCP, then, is the proposal that lets an MCP server serve its own skills over the same connection that already serves its tools. The server ships the instruction manual together with the product.

Where the spec actually stands

The interest group formed on February 1st. It became a chartered working group on April 16th. SEP-2640 is dozens of commits deep and, at the time of writing, not merged.

It also sits on the extension track. Implementing it is optional for servers and clients alike. Both sides opt in by declaring a capability, and nobody is required to support it. How much an extension spec is adopted will determine how MCP behaves in the different harnesses.

The pattern is promising enough that people are shipping anyway, including OpenAI plugins, GitHub’s MCP server, fast-agent, MCPJam, and others. Real adoption is starting before the ink is dry, which is at the same time awesome and scary.

How it works on the wire

Three pieces: a capability, a URI scheme, and a manifest with checksums.

The capability is how the two ends find out the other supports the extension. In the initialize response, under capabilities.extensions, the server declares the key io.modelcontextprotocol/skills with an empty object.

Addressing uses a skill:// scheme, followed by the skill path and then the file path. For example:

skill://acme/billing/refund/SKILL.md

The last path segment of the skill path must equal the front matter name, so the name is readable straight off the URI, and SKILL.md is always explicit.

Two new methods and one old one. skills/list returns each skill’s URI, its front matter, a revision, and a resource manifest. skills/get fetches a single skill’s entry. The files themselves travel from server to client with resources/read, the method that already exists in MCP. In the manifest, every file is declared with a URI, a SHA-256 digest, and a size, so clients can verify before writing anything to disk. If you generate skills dynamically, you mark the resources as dynamic instead. The ceiling is 512 files and 16 MB per skill.

That is the whole extension in a nutshell, simple, small, and awesome.

What you can build with it

Here’s some of the immediate patterns that the full adoption of this extension enables.

Ship the manual with the product. In my opinion this will be the main use case. MCP servers are not always agent-optimized, and it is often not obvious to the agent how to use them well. With Skills Over MCP, your server’s instructions ship together with its tools. That is a large improvement in agent experience for very little work.

Server-side updates. Change a skill on the server and every connected agent gets the new version. Nobody has to re-download anything. There is a catch here, and it is spelled OpenAI. More on that in a second.

Per-tenant skills. Your server already knows who is calling. It can serve skills based on the user’s actual profile, plan, or preferences. This is what the dynamic resources marker exists for.

Progressive disclosure. Activation is optional. A docs server can front thousands of skills. The agent holds one description each and pulls the full body only for what it needs. It is the same minimal-surface pattern we see for tools: discover, activate, execute.

Verified installs and drift detection. A client can cache skills to disk, verify integrity, and detect tampering or drift. fast-agent already does this. It treats MCP as an integrity-checked installer and refuses any file whose SHA-256 does not match.

The good

This draft shows real engineering judgment.

It introduces nearly zero new surface. Skills ride on resources, which already existed. Servers that do not support it serve nothing, and clients that do not support it see nothing unusual.

The skill format is the existing standard. One SKILL.md works on your filesystem and over the wire.

Supply-chain hygiene is in v1. Per-file SHA-256 and declared sizes. Most specs bolt that on in v3 after an incident. This one is forward-looking.

There is a real security model, written down. Skill content is untrusted input. There is no new trust here, no implicit code execution, and hooks and shell commands in front matter do not run without explicit per-skill approval. Skills never outrun user policy, and hosts should disclose which server a skill came from.

And it is bounded. 512 files, 16 MB. This is great for hosts, which can actually plan capacity.

The bad

Not all of this is the spec’s fault, but it may affect how the spec is perceived.

Optional means fragmented. Being on the extension track means capability detection everywhere, and “this skill doesn’t work on my client” becomes a permanent support category. Skills Over MCP is shaping up to be a success story for the extensions model, but fragmentation was one of the main objections during development, and the objection may prove itself correct.

Delivery is chatty. It is one resources/read call per file. Archives were cut because unpacking is an attack surface, and batching is deferred. Fine for a single skill. Less fine at fifty.

Resources are a weak foundation. A lot of MCP clients still have not implemented the resources primitive at all. Not the spec’s fault, and the MCP stable core should help as the new version gains adoption, but it is the reality today.

Models ignore skills. Early working group experiments found that agents frequently did not activate the skills available to them. This is a product problem and mostly a harness problem, not a spec problem. It will still be blamed on the spec.

The ugly

What OpenAI shipped is not what the spec describes.

OpenAI imports skills as submission-time snapshots, not as live runtime resources. You hit “scan skills”, it fetches your SKILL.md, validates it, and stores a copy in the plugin draft. Server-side skill updates do not reach OpenAI users today. The headline feature of the extension, the one that made me prefer it over plugins, does not exist in the largest implementation.

The limits are different too. The spec says 512 files and 16 MB per skill. OpenAI says five skills maximum, across ten catalog pages, 100 files per skill, 256 KiB for SKILL.md, 1 MB per file, 5 MB per skill. If you want your skills to work with both, you target the intersection. Authors are now effectively writing to the intersection of a draft and one specific vendor’s implementation.

We have been here before. Four projects independently invented four incompatible skill schemas. Shipping a partial subset of an unmerged draft at OpenAI’s distribution scale is how you recreate that problem one layer up.

What about Agent Plugins?

There is a second story tangled up with this one. It is not even MCP, but they are related and they overlap so some confusion is understandable.

Agent Plugins 1.0.0 was announced on August 6th, 2026, three weeks before OpenAI shipped Skills Over MCP. It is a vendor-neutral package format: a plugin.json manifest, a skills/ directory, and an mcp.json declaring MCP servers. It deliberately does not prescribe install or distribution.

The distinction is where the skills live and who owns them. An agent plugin is one artifact you install into your client. It is relatively static, it has a build time, and it lives client-side. You ship files, the client installs them. Skills Over MCP is a live server serving skills to whatever harness is connected. The skills are dynamic, they live in the runtime, and the server owns them.

They are complementary. But because both package MCP and skills together, there is room for confusion, and OpenAI collapsed the two. It uses Skills Over MCP as a build step to populate an agent plugin. On OpenAI, Skills Over MCP is a packaging pipeline, not a runtime protocol.

My read

A genuinely good spec with messy timing.

I love that Skills Over MCP is becoming the way to replace the giant instructions field in an MCP server. Adoption is going to be fragmented for a while, and you should know exactly what your client implements before you build on the live-update story.

For my own setups I prefer the Skills Over MCP patterns to plugins for now. Every connected client picks up the new version without anyone reinstalling anything. But the two are not incompatible. I can package an MCP server that supports Skills Over MCP inside an agent plugin. It is a distribution choice, and mostly a preference.

If you take one thing from this post, let it be this: the manual should ship with the tool, and the server should own the manual. The draft gets that right. Whether your client lets it happen is a separate question, and today the answer depends on which client.

Where Arcade fits

Arcade.dev runs MCP gateways for teams that roll tools out to a workforce, so we sit exactly where this fragmentation lands. When a skill arrives over the wire, the question that matters is not just whether the client will activate it. It is whether the agent that follows those instructions is authorized to do what they say. Skills raise the ceiling on what an agent will attempt. They do not move the enforcement boundary where auth, scopes, and identity live. That boundary stays in the runtime, on every tool call, regardless of which skill told the agent to make it and which client fetched the skill.

We are tracking SEP-2640 closely. If you are building servers or clients against it, or you have opinions about plugins versus live skills, tell me in the video comments or on X.