Agent Plugins: the new open standard

Agent Plugins is a new open standard for packaging Agent Skills and MCP servers in one portable directory. It gives compatible AI clients a shared way to find a plugin's manifest, skills, and tool connections. This is separate from OpenAI's Plugin Directory and the older ChatGPT plugins system. OpenAI helped develop the standard, but does not own it alone.

Last verified August 6, 2026: the change describing Agent Plugins as an open standard merged at 15:26 UTC, only hours before this article was written. That public framing is new; the work is not. The repository history dates to April, version 1.0.0 was published in July, and Codex CLI 0.146.0 had already announced manifest support.

There is already one same-day documentation mismatch. The current repository specification labels v1.0.0 "Published," while the rendered specification page still labels it "Working Draft." This article reports both because the two official surfaces do not currently agree.

What Agent Plugins actually standardizes

Agent Plugins defines a small interoperability floor. A conforming package has a root plugin.json manifest and can contain two portable component types:

• Agent Skills: folders of instructions, scripts, references, and assets that teach an agent a repeatable method.
• MCP servers: local or remote connections that give an agent tools, live data, and actions.

That is the entire portable core in v1. Hooks, commands, subagents, rules, user interfaces, distribution, updates, permissions, and authentication are not automatically portable.

Keeping the core this small avoids waiting for every client to agree on every feature. The package tells a compatible host where the established, cross-client parts are and how to load them. The host still decides what it supports and what the user must approve.

What an Agent Plugin contains

The Agent Plugins specification uses fixed locations instead of making every client interpret a custom layout:

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

Only plugin.json is required. The smallest valid manifest needs a schema and a lowercase plugin name:

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

Clients look for immediate child folders under skills/ that contain SKILL.md. An optional root mcp.json can declare MCP servers using stdio, Streamable HTTP, or legacy HTTP with SSE. A target client can also define and own a reverse-domain namespace such as com.example.client, using a matching directory, metadata under extensions, or both.

A portable mcp.json entry for a remote server uses the MCP configuration schema and an explicit transport:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
  "mcpServers": {
    "release-status": {
      "type": "streamable-http",
      "url": "https://tools.example.com/mcp"
    }
  }
}

The MCP server is optional. If a client cannot load that transport, it can skip the server and still load a valid skill. The failure boundaries are deliberate: a bad root manifest rejects the package, while a bad skill or individual server can be isolated without discarding everything else.

The last directory is an escape hatch, not a third portable component type. A client that does not own that namespace can ignore it.

Agent Plugins vs Agent Skills vs MCP

The easiest mental model is:

• An Agent Skill supplies the method: the sequence, judgment, examples, and quality bar for a task.
• MCP supplies access: tools, data, authentication flows, and actions outside the model's context.
• An Agent Plugin supplies the package: one predictable directory that can carry skills, MCP configuration, or both.

An SEO review skill might explain how to diagnose indexing and prioritize fixes. An MCP server might retrieve current Search Console data. An Agent Plugin can package that skill and connection together so a compatible host can discover both. Our AI skills vs MCP servers guide covers the method-versus-access distinction in more detail.

Agent Plugins does not replace Agent Skills or MCP. It composes them.

What is portable in v1, and what is not

Version 1 carries these pieces across clients:

• Plugin identity and metadata in root plugin.json.
• Skills at skills/<skill-name>/SKILL.md.
• MCP server configuration in root mcp.json.
• Standard ${PLUGIN_ROOT} and ${PLUGIN_DATA} variables for stdio MCP subprocesses, expanded in args, env, and cwd.
• Failure isolation, so one invalid skill or server does not have to disable every valid component.
• Reverse-domain namespaces for client extensions that other hosts can safely ignore.

The standard deliberately leaves several commercial and operational questions to clients:

• Where plugins are listed, sold, installed, and updated.
• Which permissions appear to users and when approval is required.
• How credentials, OAuth, and secrets are stored.
• Whether hooks, commands, agents, UI, or other extensions exist.
• How a package is reviewed, sandboxed, or trusted.

Do not confuse the standard with OpenAI's product-specific plugin format. OpenAI's current plugin authoring guide documents .codex-plugin/plugin.json and can bundle OpenAI-specific components beyond the portable v1 core. Codex supports Agent Plugins manifests, but a portable root manifest and an OpenAI directory submission are not the same contract.

Which clients support Agent Plugins now

The official compatible clients list currently names ChatGPT and Codex, VS Code, Cursor, GitHub Copilot, and Kiro. All list support for skills, stdio MCP, and Streamable HTTP. VS Code, Cursor, GitHub Copilot, and Kiro also list legacy SSE.

Support is incremental. A client may conform while supporting only skills, or only one standard MCP transport. A valid package can therefore load partially. It may also behave differently because each host controls its model, tools, permission system, and interface.

The useful promise is "one portable core, tested in each host," not "write once, run identically everywhere."

Portable does not mean trusted

The specification keeps package-provided paths inside the plugin root, but it explicitly says this is not a subprocess sandbox. A bundled MCP executable can still do whatever the host's process permissions allow.

Before installing an Agent Plugin, inspect:

• Every SKILL.md and bundled script.
• Commands, arguments, environment values, and remote URLs in mcp.json.
• Client extension directories and the extra behavior they enable.
• The permissions and credentials requested by the actual host.
• The repository, license, maintainer history, and a way to verify the output.

Do not place secrets in the package. Configured headers and environment values are visible package data, while authentication remains client-managed. A schema-valid manifest proves that the package is shaped correctly. It does not prove expertise, safety, or quality.

Should plugin authors adopt the standard now

Yes, if you maintain skills or MCP servers for more than one client. An existing package can usually be adapted in five steps:

1. Add the root plugin.json and target the 1.0.0 schema.
2. Put each portable skill in skills/<name>/SKILL.md.
3. Translate compatible server entries into the portable mcp.json shape.
4. Map host-only behavior to the target client's documented extension namespace and format.
5. Test every component and transport in each client you claim to support.

Wait if your plugin depends mainly on proprietary hooks, commands, subagents, or UI and has no useful skill or MCP core. Version 1 will not make those features portable. Client support and documentation are also moving quickly enough that the official status labels do not yet agree.

For a single skill, the package may add little today. A readable, tested SKILL.md remains the product. The standard reduces cross-client packaging friction; it does not replace the expertise inside the skill or the evidence needed to trust it. You can follow the existing Codex skill installation guide, compare free and paid AI skills, or browse AI skills.

Is Agent Plugins an OpenAI standard

Not solely. OpenAI participates in the project alongside maintainers affiliated with Amazon, Cursor, Microsoft, and Vercel. The governance rules also prevent one vendor from holding a majority of core seats.

The accurate description is a vendor-neutral standard that OpenAI helped build and already supports in Codex. The package format is shared; each client's marketplace, interface, and proprietary extensions remain separate.