Agent Plugins 1.0 lets you package a skill or MCP server once for ChatGPT, Cursor, Copilot, VS Code, Codex, and Kiro

Until this week, shipping the same agent extension to Cursor, VS Code, and ChatGPT meant maintaining a separate package for each client, and watching the copies drift apart with every update. On August 6 that changed: Amazon, Anysphere (Cursor), Microsoft, OpenAI, and Vercel published Agent Plugins 1.0.0, an open, vendor-neutral specification for packaging agent extensions, with Google joining as a core maintainer. ChatGPT, Codex, Cursor, GitHub Copilot, VS Code, and Amazon's Kiro state support at launch.

A plugin under the spec is a plain directory. The entire required surface is one manifest with two fields:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "my-plugin"
}

Around that manifest, the layout is fixed:

my-plugin/
├── plugin.json          # required: $schema + name
├── skills/
│   └── deploy-checks/
│       └── SKILL.md     # Agent Skills format
├── mcp.json             # optional: MCP server definitions
└── com.example.client/  # optional: client-specific extensions

The two payload formats are ones you already know. Skills follow the Agent Skills specification, the same SKILL.md format Claude introduced and that tools across the ecosystem have adopted. Servers in mcp.json are ordinary MCP definitions, supporting stdio, Streamable HTTP, and legacy HTTP+SSE transports. Anything a specific client needs beyond that goes into a reverse-domain namespaced directory, so one client's extras cannot break another client's install.

What to do with the packages you maintain now

If you distribute a skill or an MCP server to users on more than one client, the repackaging is small and worth doing this week. Move your SKILL.md directories under skills/, describe your server in mcp.json, add the two-field manifest, and you have one artifact that installs in six clients. The per-client forks you have been patching in parallel become one directory with one changelog. AWS has already converted its Agent Toolkit, over 30 skills and MCP servers, to the format, and Google ships support in its Agents CLI and Data Agent Kit.

Teams with internal tooling get the same benefit privately. If your onboarding doc currently explains how to wire the internal deployment skill into Cursor, then separately into VS Code, then separately into Copilot, that doc collapses into one plugin in one repository. This pairs directly with the migration work many teams did this summer: an MCP server you moved to Streamable HTTP drops into mcp.json as-is.

If you are choosing a format for a new skill today, write it to the Agent Skills spec regardless of which client you target first. That is now the portable layer. Our skills library follows the same format, so anything you pick up there packages cleanly.

The Claude Code line to be careful about

One absence matters practically. Both payload formats in this spec originated at Anthropic: Agent Skills and the Model Context Protocol. Yet Anthropic is not on the technical steering committee, and Claude Code is not on the compatibility list. Claude Code has its own plugin format, and its August 7 release (2.1.224) extends that separate system with zip-based plugin installs and SHA-256 pinning.

The practical consequence: do not throw away your Claude Code packaging in the cleanup. The SKILL.md content itself is identical between the two worlds, because both point at the same Agent Skills specification. The wrapper is what differs. Structure your repository so the skills/ directories are the shared source of truth, and treat the Agent Plugins manifest and the Claude Code plugin layout as two thin wrappers around it. If Anthropic later adopts or bridges the standard, you delete a wrapper; until then you maintain two small files instead of two forks.

Two caveats before you rely on the launch claims. Day-one support is each vendor's statement about its own client, and install flows differ between them, so verify the actual install path in each client you target before telling your users it works. And the namespaced extensions directory is where fragmentation can quietly return: the more client-specific configuration your plugin needs, the less the portability buys you. Keep the shared payload large and the namespaced extras minimal, and the standard does what it promises.