On August 6, OpenAI, Amazon, Microsoft, Cursor, and Vercel shipped Agent Plugins 1.0.0 — an open, vendor-neutral standard for packaging AI agent extensions that work across ChatGPT, GitHub Copilot, Cursor, Kiro, VS Code, and Codex without rebuilding for each platform. Six clients supported the standard on launch day, which is the kind of immediate multi-platform buy-in that most open standards take years to achieve. The format bundles two components: Agent Skills (SKILL.md instruction files that teach agents repeatable tasks) and MCP server configurations — packaged together in a simple directory that any compatible client can read.
Why AI Tool Builders Were Duplicating Work #
Before this standard, every AI coding client expected a different folder layout. Developers building the same tool for ChatGPT and Cursor had to maintain two separate packages. Add Copilot and Kiro to the mix and you’re maintaining four. Vercel reportedly originated the Agent Plugins proposal — though the OpenAI-led announcement obscured that — suggesting the fragmentation pain was acute enough for a platform with a smaller developer user base to push the solution forward. The fact that five separate companies co-designed it, rather than OpenAI shipping it alone and hoping others follow, is the strongest signal this solved real shared pain across the ecosystem.
Adoption is additive, not breaking. Cursor still ships its own .cursor-plugin/plugin.json
alongside the Agent Plugins standard. OpenAI maintains .codex-plugin/plugin.json
in parallel. Adding a conformant manifest to an existing plugin expands its reach without abandoning platform-specific behavior — which is why the standard picked up six clients immediately rather than five months later.
Related:[MCP 2026-07-28 Goes Stateless: What Breaks and How to Migrate]
A Plugin Is a Directory #
The format’s defining characteristic is its simplicity. A plugin is a directory. The manifest requires exactly two fields. There is no required CLI tooling, no registry to publish to, and no binary format — the directory is inspectable with standard Unix tools and version-controllable from day one. That readability matters when the spec ships without built-in verification.
my-plugin/
├── plugin.json # requires: $schema + name only
├── skills/
│ └── run-tests/
│ └── SKILL.md # instructions for the agent
└── mcp.json # optional MCP server config
The minimum plugin.json
is two fields: a $schema
pointer and a lowercase name
under 64 characters. Everything else — version, description, author, license — is optional. Skills live in skills/<name>/SKILL.md
. MCP server connections are declared in mcp.json
, supporting stdio, Streamable HTTP, and legacy SSE transports. According to AgenticSkills.io’s technical reference, failure isolation is built in — a broken skill doesn’t disable the MCP configuration, and a misconfigured MCP server doesn’t take the whole plugin down.
What v1.0.0 Doesn’t Cover #
The spec defines packaging only. Permissions, sandboxing, cryptographic signing, provenance tracking, publisher identity, audit trails, and secret handling are all explicitly deferred to future versions with no committed dates. VS Code’s own documentation states plainly that “plugin MCP servers are implicitly trusted when you install the plugin.” The spec page itself carries a “Working Draft” status label despite calling itself version 1.0.0, with no corresponding git tags or GitHub Releases at launch.
The trust problem predates this standard, but Agent Plugins expands it. An analysis of audited MCP servers found that 43% publish no auditable source code and zero include software bills of materials. Portability means a plugin can now reach six clients from one package — but the trust surface scales with that reach. The spec’s own language makes this explicit: “containment is not sandboxing.” Plugin processes execute with whatever permissions the host client grants.
For Publishers and Consumers Right Now #
If you build agent extensions, adoption is low-cost: add a conformant plugin.json
and a skills/
directory, and your plugin becomes compatible with six clients. Google shipped two concrete implementations on launch day — Agents CLI and Data Agent Kit — rather than just an endorsement. Claude Code gains compatibility through the npx plugins add
CLI, which translates the format into Claude’s native plugin system; Anthropic didn’t sign the spec but didn’t block it either.
If you consume plugins, treat installation as code execution. Review the plugin directory before running it. Pin specific versions rather than tracking branches. Examine every MCP command, argument, and remote URL listed in mcp.json
. For enterprise deployments, implement access controls at the client level now — the spec will not standardize permission models before v1.1, and there is no committed timeline for that release.
Key Takeaways #
- Agent Plugins 1.0.0 shipped August 6 with six supporting clients — the broadest day-one adoption of any AI agent packaging standard to date
- The format is additive: a conformant manifest expands reach without breaking existing vendor-specific plugin configurations
- v1.0.0 covers packaging only — no permissions, no signing, no sandboxing; plugin processes run with whatever permissions the host client grants
- Publishers: low adoption cost, high reach — add plugin.json and a skills directory to your existing extension
- Consumers: treat every plugin install as code execution — inspect source, pin versions, audit mcp.json commands before running