Agent Plugins 1.0.0: One Package Format for Agent Skills and MCP Servers

Last updated: August 6, 2026

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:

{
  "$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 and the case for skills over prompts 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 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 - 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.

FAQ#

What is Agent Plugins 1.0.0?#

Agent Plugins 1.0.0 is an open, vendor-neutral standard, published by Vercel on August 6, for packaging Agent Skills and MCP servers into distributable plugins. A plugin is a directory with a required plugin.json manifest and fixed locations for its components.

Which agent clients support Agent Plugins?#

Six clients ship support at launch: ChatGPT and Codex, Cursor, GitHub Copilot, Kiro, and VS Code. All of them can load both component types, Agent Skills and MCP servers.

What does a minimal plugin.json need?#

The minimum manifest is two fields: a $schema pointing at the 1.0.0 plugin schema and a name. Everything else is file structure - skills live under skills/ in the existing Agent Skills format, and MCP servers are described in mcp.json.

Does Agent Plugins include a registry or install command?#

No. Version 1 has no canonical registry, no install command, and no marketplace. Distribution, installation, permissions, policy, and user experience all stay under each client's control.

Continue Reading#

• Agent Skills Are Becoming Package Managers - why governance, not prompts, is the pattern that wins
• MCP Servers vs Agent Skills in 2026 - the two component types Agent Plugins packages, compared
• Why Skills Beat Prompts for Coding Agents - the case for skills as the portable unit of agent behavior
• Vercel MCP Ships the 2026-07-28 Spec - the protocol momentum Agent Plugins builds on
• What Is the Model Context Protocol - 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
• Custom GPTs Retire Dec 11, 2026: How to Migrate to ChatGPT Plugins - what the migrate button moves and why custom Actions need an MCP rebuild

Sources#

• Vercel blog: Introducing Agent Plugins (August 6, 2026)
• Vercel changelog: Agent Plugins 1.0.0 (August 6, 2026)
• Agent Plugins specification and compatible clients (agent-plugins.org, accessed August 6, 2026)
• agentplugins/agent-plugins-spec repository (governance and contribution process)