This site does not allow itself to be embedded. You can still read it on the original site — the toolbar below keeps your place in the directory.
Vercel, OpenAI, GitHub, Microsoft, AWS, and Cursor collaborated on Agent Plugins 1.0.0, an open standard that packages Agent Skills and MCP servers into one portable plugin. ChatGPT, Codex, Cursor, GitHub Copilot, Kiro, and VS Code load the format on day one.
On August 6, Vercel published Agent Plugins 1.0.0, an open, vendor-neutral standard for packaging Agent Skills and MCP servers into distributable plugins. The format is deliberately tiny: a directory with a `plugin.json` manifest and fixed locations for components. Six agent clients ship support at launch - ChatGPT and Codex, Cursor, GitHub Copilot, Kiro, and VS Code - and all of them can load both component types on day one.
The project is as notable for who is in it as for what it does. Vercel initiated the proposal; representatives from AWS, Anysphere, GitHub, Microsoft, and OpenAI refined it into the 1.0.0 release. The Technical Steering Committee lists core maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel, and the project claims no single company's product roadmap sets the format's direction. Governance is public: the specification repo has been developed in the open since April 2026, material changes begin as GitHub Discussions, and the docs are licensed CC BY 4.0.
## The format in one directory
An Agent Plugin is a directory with a required manifest and optional components in fixed locations:
```
my-plugin/
├── plugin.json
├── skills/
│ └── summarize/
│ ├── SKILL.md
│ ├── scripts/
│ └── references/
├── mcp.json
└── com.example.client/
└── hooks/
```
`plugin.json` identifies the plugin and targets a spec version. The minimum manifest is two fields:
```json
{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "my-plugin"
}
```
Everything else is file structure. `skills/` holds Agent Skills in the existing Agent Skills specification format - `SKILL.md` with `name` and `description` frontmatter, plus optional `scripts/` and `references/`. `mcp.json` describes MCP servers over stdio, Streamable HTTP, or the legacy HTTP+SSE transport. Clients check for `plugin.json` at the root, discover the components they support, and validate each component independently, so one invalid component does not disable the rest of the plugin.
Client-specific behavior lives in reverse-domain namespaces such as `com.example.client/`. Other clients ignore those namespaces, which keeps vendor features from leaking into the portable contract. A client can support either component type or both - the spec defines what is portable, not which parts a given client must load.
## What it deliberately leaves out
Version 1 is a small interoperability floor, not a marketplace. Distribution, installation, permissions, policy, and user experience all stay under each client's control. The scope covers exactly two component types, Agent Skills and MCP servers, both of which already have their own mature specifications - Agent Plugins does not redefine either. Commands, hooks, and agents remain client-specific for now; the Technical Steering Committee may add component types in future versions only when a demonstrated portability need and implementer support exist.
## Why the launch support matters
The same clients that each invented their own plugin conventions are the ones agreeing on this one. The practical effect for authors is the end of the repackaging tax: today a skill or MCP server with identical content needs client-specific metadata, discovery paths, and MCP configuration per target. Our coverage of the [skills versus MCP split](/blog/mcp-servers-vs-agent-skills-2026) and the case for [skills over prompts](/blog/why-skills-beat-prompts-for-coding-agents-2026) kept circling the same friction: the underlying component is portable, the packaging is not. Agent Plugins targets exactly that seam.
It is also the direct continuation of two trends we have been tracking. The [skill registry and package-manager trajectory](/blog/agent-skills-package-manager-governance) we covered in May assumed the ecosystem would converge on governance and dependency handling for agent instructions; a shared package format is the structural prerequisite for that to happen across vendors rather than inside one client. And the standard ships in the same month the MCP 2026-07-28 spec went live in production servers like [Vercel MCP](/blog/vercel-mcp-2026-07-28-spec-support) - the tooling ecosystem is consolidating around a small set of shared contracts for the first time.
## Honest caveats
The standard is young and deliberately thin. There is no distribution or discovery mechanism in v1 - no canonical registry, no install command, no marketplace. "Portable" means a client that implements the conformance checklist can load your plugin; it does not mean your users can find it. ChatGPT and Codex support MCP over stdio and Streamable HTTP but not the legacy HTTP+SSE transport, so a plugin targeting every launch client should pick modern transports. And because each client controls installation and UX, the experience of installing the same plugin still differs by client even when the payload does not.
## What to do now
If you author skills or MCP servers: the cheap first step is a directory restructure - `plugin.json` at the root, `SKILL.md` files under `skills/`, servers described in `mcp.json`. The manifest schema is public, and the spec's author guide walks through a minimal plugin with one skill. If you build an agent client, the conformance checklist defines the minimum for discovering and loading plugins, and you can support components incrementally.
The things to watch: whether plugin registries and marketplaces emerge on top of the format, whether the TSC adds component types in 1.1, and how quickly the six launch clients converge on install and permission flows. A standard this small is easy to implement; the hard part is the ecosystem actually using it.
## Continue Reading
- [Agent Skills Are Becoming Package Managers](/blog/agent-skills-package-manager-governance) - why governance, not prompts, is the pattern that wins
- [MCP Servers vs Agent Skills in 2026](/blog/mcp-servers-vs-agent-skills-2026) - the two component types Agent Plugins packages, compared
- [Why Skills Beat Prompts for Coding Agents](/blog/why-skills-beat-prompts-for-coding-agents-2026) - the case for skills as the portable unit of agent behavior
- [Vercel MCP Ships the 2026-07-28 Spec](/blog/vercel-mcp-2026-07-28-spec-support) - the protocol momentum Agent Plugins builds on
- [What Is the Model Context Protocol](/blog/what-is-model-context-protocol-2026-primer) - the MCP primer for anyone new to the stack
- [Vercel Sandbox Gets a Real Network Boundary: Why Egress Control Is the Missing Half of Agent Security](/blog/vercel-sandbox-network-boundary-egress-2026)
## Sources
- [Vercel blog: Introducing Agent Plugins](https://vercel.com/blog/introducing-agent-plugins) (August 6, 2026)
- [Vercel changelog: Agent Plugins 1.0.0](https://vercel.com/changelog/introducing-agent-plugins-1-0-0) (August 6, 2026)
- [Agent Plugins specification and compatible clients](https://agent-plugins.org) (agent-plugins.org, accessed August 6, 2026)
- [agentplugins/agent-plugins-spec repository](https://github.com/agentplugins/agent-plugins-spec) (governance and contribution process)Read on developersdigest.tech ↗
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.