Agent Plugins: OpenAI's New Open Standard for Packaging AI Agent Tooling

OpenAI Developers announced Agent Plugins on August 6, 2026 at roughly 9:41pm PT: "Build a plugin once and use it across compatible agent clients. Introducing Agent Plugins, an open standard developed with AWS, Cursor, GitHub, VS Code, and Vercel — that packages Agent Skills and supports MCP server configurations in a shared format." The post crossed 1.1M+ views within a day, and community reaction to the standard itself was strongly positive.

If you already work with Agent Skills or MCP servers, this matters directly: Agent Plugins is not a third, competing format. It is the portability layer over both, so compatible clients can discover the same skill-plus-tooling directory without every vendor inventing a different core package layout.

Update — August 11, 2026: The initial announcement has become an implementable specification. The official project now publishes an Agent Plugins v1.0.0 Working Draft, canonical JSON schemas, author and client implementation guides, public governance, and an expanded compatibility matrix. The standard is much more concrete than it was on August 7, but 1.0.0 is still labelled Working Draft, not a frozen final standard.

TL;DR — the questions developers are actually asking

What is an Agent Plugin, exactly?

An Agent Plugin is a packaging standard, not a new runtime or a new instructional format. Based on OpenAI Developers' own description, it bundles two things that already existed separately in the agent-tooling ecosystem:

1. Agent Skills — packaged instruction sets (the SKILL.md-style pattern explainx.ai has covered extensively: progressive disclosure, portable playbooks, rules vs. skills vs. MCP)
2. MCP server configurations — the connection details for Model Context Protocol servers that give the agent live tools, resources, and prompts

Agent Plugins packages both into "a shared format." The now-published specification makes that phrase precise: a conformant package is a directory with a root plugin.json, optional skills in fixed subdirectories, and optional MCP configuration in root mcp.json. A compatible client can load the same portable files, though each client still owns how the plugin is distributed, installed, enabled, permissioned, updated, and shown in its UI.

Think of the layering this way:

How do I package an Agent Plugin now that v1.0.0 is published?

The exact shape is no longer a mystery. The official author guide defines a self-contained directory and fixed discovery locations:

hello-plugin/
├── plugin.json
├── skills/
│   └── greet/
│       └── SKILL.md
└── mcp.json

The smallest valid root manifest needs only the canonical schema identifier and a name:

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

The plugin.json schema is closed. Along with the two required fields, v1 allows version, description, author, homepage, repository, license, keywords, and extensions. Plugin names are 1–64 characters, use lowercase ASCII letters, digits, hyphens, and periods, begin and end with an alphanumeric character, and cannot contain -- or ...

Existing Agent Skills generally need no content rewrite if they already conform to the Agent Skills specification: put each one at skills/{name}/SKILL.md. Existing MCP server code also need not change merely because it is packaged, but client-native configuration may. Agent Plugins uses a separate closed mcp.json schema with explicit stdio, streamable-http, or legacy sse transport variants, so do not paste a Cursor, Claude, Codex, or VS Code config and assume it is portable.

Which agent clients support Agent Plugins today?

The launch announcement named six clients. By August 11, the official compatibility matrix had expanded to seven client entries, with ChatGPT and Codex grouped together:

Compatibility is incremental, not all-or-nothing. The v1 conformance rules let a client support only skills or only one standard MCP transport, provided it satisfies the requirements for the component types it claims. That is why the matrix records components and transports rather than showing a misleading single green checkmark. Vercel remains represented in the project's governance, but the matrix does not list a Vercel-branded client.

This is a genuine multi-vendor project rather than an OpenAI-only format dressed up with partner logos. The project repository says its initial Technical Steering Committee includes core maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel. The structure resembles the ecosystem cooperation explainx.ai covered when GitHub's Copilot SDK shipped a shared agent runtime across six languages, and it matters because Claude Code, Cursor, and GitHub Copilot otherwise expose different extension surfaces.

Why not just extend MCP or Agent Skills instead of a new standard?

Because the two existing standards solve genuinely different, narrower problems, and neither one defines packaging:

• MCP defines the wire protocol and trust model for an agent to discover and call tools at runtime — it says nothing about how a bundle of "this skill plus this MCP server" gets versioned, distributed, and installed as a single artifact.
• Agent Skills defines the instructional package format — but a skill that depends on a specific MCP server has historically needed separate, undocumented setup instructions to wire the two together, repeated per client.

Agent Plugins fills that specific gap: a shared package and loading contract. The distinction matters. The official build guide explicitly leaves distribution, installation, enablement, updates, and user interface outside the portable specification. A plugin can therefore be structurally portable while still requiring a different install command or marketplace flow in each client.

The fact that multiple vendors developed the format is still the strongest signal that this was shared pain across the ecosystem, not a speculative OpenAI initiative. It also lands alongside broader 2026 work on portable agent tooling: MCP for runtime tool-calling, WebMCP for site-exposed tools, and Agent Plugins for carrying skills and MCP configuration in one inspectable directory.

Is this a competitor to Anthropic's Agent Skills format?

No. OpenAI Developers' own description says Agent Plugins "packages Agent Skills" — present tense, as a stated capability, not "packages a new alternative to Agent Skills." That framing positions Agent Plugins as a distribution layer built to wrap the existing Agent Skills format, the same one explainx.ai's complete guide to agent skills documents in depth, rather than a rival instructional spec competing for the same job.

What v1.0.0 defines — and what it deliberately leaves to clients

The normative v1.0.0 specification resolves most of the day-one questions:

• Manifest and discovery: root plugin.json is mandatory. Skills are discovered only from immediate children of skills/; MCP configuration comes only from root mcp.json.
• Versioning: both files declare canonical versioned schema URLs. When both exist, their Agent Plugins schema versions must match. Plugin versions should use Semantic Versioning.
• MCP transports: stdio and streamable-http are the standard transports; legacy sse is optional. A conformant MCP-capable client must support at least one of the first two.
• Portable paths and state: clients supply ${PLUGIN_ROOT} and ${PLUGIN_DATA} to stdio subprocesses. Package paths must remain inside the plugin root; PLUGIN_DATA is the client-managed writable location that persists across updates.
• Failure isolation: an invalid MCP server entry disables that entry, not valid skills or other servers. A bad root manifest is fatal to the whole plugin.
• Client extensions: vendor-specific data lives under reverse-domain namespaces such as com.example.client, keeping experiments outside the portable core.

The remaining limits are now explicit rather than merely unknown:

• Working Draft status: the published release is named 1.0.0, but the spec still labels itself a Working Draft. Pin the schema URL and expect future revisions.
• No portable installer or marketplace: distribution, installation, enablement, update delivery, permissions, and UI remain client-owned.
• No portable OAuth fields: v1 defines no OAuth or credential-reference fields. Authentication discovery, consent, and credential storage are handled by the client.
• Only two portable component types: skills and MCP servers are the v1 interoperability floor. Commands, hooks, subagents, rules, and LSP servers remain client-specific unless represented through a namespaced extension.
• Containment is not sandboxing: rejecting paths that escape the plugin root prevents package traversal, but it does not sandbox a launched MCP subprocess. Users and clients still need a trust and approval model.

That is a deliberately narrow standard. It gives plugin authors a package another conformant client can inspect and load without pretending that every product has converged on permissions, marketplaces, or UX.

Not to be confused with: OpenAI's earlier "Codex plugins" repository

If you've been tracking OpenAI's Codex ecosystem, note that the portable v1 format is not identical to every client-native package called a plugin. The official Codex plugins repository, for example, uses a .codex-plugin/plugin.json manifest and supports Codex-specific companion surfaces. The vendor-neutral Agent Plugins spec instead requires plugin.json at the package root and isolates client additions under reverse-domain extension namespaces. Do not rename files blindly between the two formats; follow the target client's setup guide and the portable spec separately.

It is also distinct from the Codex plugin for Claude Code, a Claude Code marketplace plugin that lets Claude Code call the Codex CLI. That is a one-client integration, not the Agent Plugins portability contract.

Bottom line

Agent Plugins now has enough detail to build against: a versioned root manifest, fixed skill and MCP locations, canonical schemas, explicit transport rules, path containment, state directories, failure isolation, and namespaced client extensions. It does not replace MCP or Agent Skills, and it does not make installers, marketplaces, permissions, or update systems portable. The multi-vendor governance plus the addition of Hermes Agent and OpenClaw to the official matrix shows adoption moving beyond the original launch group; the Working Draft label is the reason to keep schema versions pinned and re-check the spec before production release.

Related reading

• ChatGPT Apple Messages on Mac — privacy guide (Aug 21) — a high-privilege public plugin in Codex and Work
• How to Use Skills in ChatGPT: Complete Guide — the ChatGPT-side walkthrough of Skills vs. this Plugin standard
• Diagram Design: the Claude Code skill that ships natively across Claude Code, Codex, and Pi — a concrete example of the cross-client packaging problem this standard addresses
• Qwen-MM-Plugins: multimodal capability packs for nine harnesses — Alibaba shipping skills+MCP bundles into Claude Code, Codex and Gemini CLI
• What are agent skills? Complete guide for Claude Code, Cursor & MCP
• What is MCP? Model Context Protocol: Complete Architecture Guide
• GitHub Copilot SDK: multi-platform agent development
• Claude Code vs Cursor vs GitHub Copilot
• OpenAI's official Codex plugins repository (Figma, Notion, iOS, web)
• OpenAI Codex plugin for Claude Code — setup guide
• CLAUDE.md vs SKILL.md vs MCP: the modern agent stack
• Browse the explainx.ai skills registry →
• Browse the explainx.ai MCP server directory →

Official sources: Agent Plugins specification v1.0.0 · build guide · compatible clients · specification repository and governance · OpenAI plugin docs.

This article reflects Agent Plugins Specification v1.0.0 and the official compatibility matrix as checked on August 11, 2026. The release is marked Working Draft; re-check agent-plugins.org before building against it.