Agent Plugins 1.0 Sets a Portable Floor for Skills and MCP Servers

AI-generated conceptual illustration of a portable agent-plugin package connecting instructions and a tool server to multiple neutral client interfaces; not a product screenshot or implementation diagram. Credit: OpenAI ImageGen / GeethanTech.

Agent Plugins 1.0.0 became publicly available on August 6, 2026, establishing an open format for packaging Agent Skills and Model Context Protocol servers so compatible AI-agent clients can discover them in predictable locations. The launch announcement from Vercel describes it as a vendor-neutral standard, but its practical promise is narrower than a universal “write once, run everywhere” layer.

Agent Plugins standardizes the portable middle of an extension package. It does not define a shared marketplace, permission screen, credential store, installation process or user experience. Those remain decisions for each client.

What the 1.0.0 package standardizes

The normative Agent Plugins 1.0.0 specification, which currently carries “Working Draft” status, defines a plugin as a directory with a required plugin.json manifest at its root. Skills are discovered under skills/, while MCP server configuration belongs in a root-level mcp.json file.

my-plugin/ ├── plugin.json ├── skills/ │ └── summarize/ │ └── SKILL.md ├── mcp.json └── com.example.client/

A minimal portable manifest needs only two fields: $schema, which identifies the Agent Plugins specification version, and name. Version, description, author, repository, licence and keywords are optional metadata. The fixed component locations are not configured inside the manifest, which keeps discovery deterministic.

Version 1 defines exactly two portable component types: Agent Skills and MCP servers. A package may contain either or both, and a conformant client can support one component type without supporting the other. An absent component is not an error, while invalid components are handled independently where the specification allows it.

Skills and MCP servers remain different layers

Skills package repeatable instructions and supporting resources. Each skill is a folder containing a SKILL.md file and, when needed, scripts, references, templates or assets. MCP servers provide a different layer: callable tools, input and output schemas, authentication requirements, structured results and connections to external systems.

OpenAI’s plugin architecture documentation illustrates the distinction for ChatGPT and Codex. A plugin can contain skills, an MCP server, or both. An MCP server can optionally return custom interface resources, but UI is not required. OpenAI recommends beginning with the smallest package shape that satisfies the workflow and adding server-backed tools or UI only when the use case needs them.

The portable format does not replace client packaging

The project describes Agent Plugins as an interoperability floor. Installation, distribution, permissions, policy, user experience and client-specific capabilities remain outside the portable core. Clients can add manifest data or files under reverse-domain namespaces, such as com.example.client, without assigning those extensions portable meaning.

This boundary matters because client documentation can still use a different authoring or distribution layout. OpenAI’s current packaging guide for ChatGPT and Codex requires a .codex-plugin/plugin.json manifest and uses .app.json for a registered MCP connection or .mcp.json for a bundled MCP server. That is distinct from the portable specification’s root plugin.json and mcp.json. Builders targeting OpenAI products should follow OpenAI’s current product guide for that publishing route instead of assuming the portable directory alone completes installation.

Client support does not guarantee feature parity

Vercel’s launch post lists ChatGPT and Codex, Cursor, GitHub Copilot, Kiro and VS Code as supporting Agent Plugins at launch. That support should not be read as identical component, transport, extension or marketplace coverage. The specification explicitly permits incremental adoption and requires clients to ignore component types they do not implement.

Teams should therefore test each target client rather than treating format conformance as runtime equivalence. The specification requires package paths to stay within the plugin root, but notes that those containment rules do not sandbox an MCP subprocess. It also leaves OAuth, credential storage and user authorization interactions to clients, and warns that configured headers and environment values are not portable secret mechanisms.

An open project with a deliberately small core

Vercel says it initiated the proposal before representatives from AWS, Anysphere, GitHub, Microsoft, OpenAI and Vercel refined version 1.0.0. The project’s initial Technical Steering Committee includes core maintainers from AWS, Cursor, Microsoft, OpenAI and Vercel. Its documentation and technical work are public, with the project site published under CC BY 4.0.

For extension authors, the immediate value is a stable place for the reusable parts: skill folders, MCP configuration and a small manifest. The useful engineering strategy is to keep that portable core clean, isolate client-specific additions, review plugins as executable or tool-enabled software, and validate packaging, permissions and component support separately in every intended client.