What Anthropic Skipping Agent Plugins 1.0 Actually Costs

On August 6, 2026, AWS, Microsoft, OpenAI, Vercel, and Cursor shipped Agent Plugins 1.0.0 — a shared, vendor-neutral format for packaging AI agent skills and MCP servers into portable plugins. Google joined the same day as a Core Maintainer. Launch clients already include VS Code, GitHub Copilot, Cursor, ChatGPT, and Kiro.

Anthropic isn't on the list. Which is a little strange, because the spec's skills/ component is required to conform to Anthropic's own Agent Skills format — the same one Claude Code has used for its skills system all along. The company that wrote the foundation didn't join the group that built on top of it.

I wanted to know what that absence actually costs, in practical terms. Not "is this bad for Anthropic" — I have no read on that — just: if I take a real Agent Plugins 1.0.0 package today, how much work is it to make it run in Claude Code anyway?

Reading the actual spec first

Before touching anything I pulled the real repos instead of trusting news summaries: agentplugins/agent-plugins-spec for the JSON Schemas and agentplugins/agent-plugins-example for a canonical package. A plugin under the new spec is deliberately minimal — a directory with plugin.json at the root, an optional skills/ folder, and an optional mcp.json. Ten permitted top-level fields in the manifest, closed schema, unknown fields get reported but don't reject the package.

Then I read Claude Code's own plugin reference. And the closer I looked, the more the two formats started to look like siblings rather than strangers.

Where they actually diverge

Turns out there are exactly three real gaps:

The manifest lives in a different spot. Agent Plugins wants plugin.json at the package root. Claude Code wants it at .claude-plugin/plugin.json. Same fields underneath — name, version, description, author, homepage, repository, license, keywords — just a different address.

MCP config has a different filename. mcp.json becomes .mcp.json, dot-prefixed, also at the plugin root. I was expecting the server definitions themselves to need translation — different transport naming, different field names, that kind of thing. They don't. Claude Code's .mcp.json accepts stdio, streamable-http, and sse server blocks in the identical shape the Agent Plugins schema defines, command/args/env or url/headers and all. Claude Code's own docs even call out streamable-http as a documented alias for http, presumably because someone there was already looking at the same MCP ecosystem everyone else is.

Two placeholder tokens have different names. Agent Plugins uses ${PLUGIN_ROOT} and ${PLUGIN_DATA}; Claude Code uses ${CLAUDE_PLUGIN_ROOT} and ${CLAUDE_PLUGIN_DATA}. That's it. A find-and-replace.

Everything in skills/ needed zero changes. Both formats point at the same underlying Agent Skills spec, so a SKILL.md written for one is already valid for the other. I copied the directory byte for byte and it just worked.

Writing the bridge

I wrote a single-file Python script, no dependencies outside the standard library, that does exactly those three things: relocate the manifest, rename the MCP config, rewrite the two tokens. agent-plugins-bridge if you want the whole thing — it's short enough to read end to end in a few minutes.

I tested it two ways. First, against the canonical example package from the spec's own repo:

$ python3 agent_plugin_to_claude.py agent-plugins-example/ converted-example
Converted 'agent-plugins-example': 1 skill(s), no mcp.json

$ claude plugin validate ./converted-example
⚠ Found 1 warning:
  ❯ author: No author information provided. Consider adding author details for plugin attribution
✔ Validation passed with warnings

That's the real claude plugin validate command, not something I mocked up. It passes with one cosmetic warning because the example package doesn't set an author field — nothing about the conversion itself.

Then I wanted proof the skill was actually usable, not just that the manifest parsed, so I loaded it into a live session with --plugin-dir and asked directly:

$ claude -p --plugin-dir ./converted-example \
    "Without doing anything else, tell me: do you currently have a skill \
     available named migrate-agent-plugin? Answer in one sentence."

Yes — agent-plugins-example:migrate-agent-plugin is available in this session.

Second test, a synthetic package I wrote myself specifically to exercise the mcp.json path — the canonical example doesn't ship one — with a stdio server and a streamable-http server, both using the ${PLUGIN_ROOT}/${PLUGIN_DATA} placeholders in command, args, env, and cwd. Converted output had every placeholder correctly rewritten and validated the same way. I'd half-expected the transport blocks to need real translation; they didn't need any.

What this doesn't settle

I want to be careful not to overstate this. The Agent Plugins spec explicitly scopes itself to the portable core — skills and MCP servers — and says distribution, provenance/signing, and permission models are left to each platform. That's a reasonable design choice for a v1.0.0, but it's also exactly where a five-vendor "open standard" could still fragment back into five separate marketplaces with five separate trust models sitting on top of one shared file format. Nothing I built here touches that layer, and nothing here tells you whether it stays open once each vendor ships their own store on top of it.

What I can say is narrower: the part of the standard that ships today — the part everyone can point to and say "look, it's portable" — turned out to be portable to a platform that never signed the announcement. Not because I did anything clever. Because the underlying skills format was already Anthropic's to begin with, and the MCP layer both sides use is close enough that renaming a couple of files and two environment variable names was the entire job.

Repo's here if you want to try it against your own packages: github.com/yama3133/agent-plugins-bridge