OpenAI Agent Plugins: Portable Skills and MCP Explained

Verdict: Agent Plugins is a serious interoperability play for AI agents, not a new model or another marketplace. Its 1.0.0 format is deliberately small: a root plugin.json, fixed locations for Agent Skills and MCP configuration, and a namespaced escape hatch for client-specific behavior. That makes it easier to package an agent capability once and move it between compatible clients. It does not make plugins safe by default, guarantee identical behavior everywhere, or solve the hard parts of trust and permissions.

That distinction matters. OpenAI’s launch lands at the moment when coding agents are becoming configurable operating environments rather than chat windows. Every client has learned to load instructions, tools, scripts, hooks, and integrations in its own way. Agent Plugins tries to standardize the portable layer underneath.

What OpenAI announced

On August 6, 2026, OpenAI Developers announced Agent Plugins as “an open standard” developed with AWS, Cursor, GitHub, @code, and Vercel. The announcement’s pitch is simple: build a plugin once and use it across compatible agent clients. A follow-up post lists Codex, ChatGPT, Cursor, GitHub Copilot, Kiro, and @code among the launch-compatible clients. The public specification site currently documents support from VS Code, Cursor, GitHub Copilot, ChatGPT and Codex, and Kiro, with support varying by component and MCP transport.

The project’s own documentation calls Agent Plugins an open, vendor-neutral standard for packaging reusable components that extend AI agents. Its initial technical steering group includes maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel. The specification repository is public, and the governance charter says participation is open to anyone who follows the project’s rules.

The important word is format. Agent Plugins does not prescribe one store, one installer, one user interface, or one agent runtime. It establishes a predictable package layout and loading contract that different clients can implement.

What the package actually contains

A portable plugin is a directory. The minimum manifest is a file named plugin.json at the root:

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

The manifest identifies the package and the version of the Agent Plugins contract it targets. Optional metadata includes a version, description, author, homepage, repository, license, keywords, and an extensions object for client-owned data. The schema is intentionally closed: unknown top-level fields are reported and ignored, while other manifest violations can cause the client to reject the plugin before it discovers any components.

The portable package has three relevant surfaces:

Component	Portable location	What it does
Agent Skills	`skills/<name>/SKILL.md`	Packages instructions and supporting files that teach an agent how to perform a repeatable task.
MCP servers	`mcp.json`	Describes MCP connections that a client can map to its native runtime.
Client extensions	`extensions` or a top-level reverse-domain directory	Holds behavior that is useful to one client but is not part of the portable core.

The fixed locations are a meaningful design choice. A plugin cannot move its skills somewhere else by adding a custom path to the manifest. A client scans the agreed locations, validates what it supports, and ignores component types it does not implement. A package can therefore be useful in a skills-only client even when it also contains MCP configuration that the client cannot run.

How MCP fits in

Agent Plugins is not a replacement for the Model Context Protocol. MCP remains responsible for the wire behavior and lifecycle of the connection. Agent Plugins standardizes where the MCP configuration lives and how a client maps it into its own runtime.

An mcp.json file can describe local stdio servers, current Streamable HTTP servers, and the older HTTP+SSE transport. A typical configuration looks like this:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
  "mcpServers": {
    "local-validator": {
      "type": "stdio",
      "command": "./bin/validator",
      "args": ["--data", "${PLUGIN_DATA}/validator"],
      "cwd": "${PLUGIN_ROOT}"
    },
    "deployment-api": {
      "type": "streamable-http",
      "url": "https://deploy.example.com/mcp"
    }
  }
}

The standard reserves two runtime variables. PLUGIN_ROOT points to the installed package, while PLUGIN_DATA points to client-managed writable data that can survive plugin updates. Clients expand those variables in arguments, environment values, and working directories. They do not expand them in the executable command, URL, or HTTP headers.

That last detail is part of the security boundary. The specification says configured headers and environment values are visible package data, not a portable secret mechanism. Version 1.0.0 defines no OAuth fields and no cross-client credential format. Authentication, credential storage, and user interaction remain client-managed.

Why portability matters

Agent developers currently face a packaging tax. The same workflow may need one format for Cursor, another for Copilot, another for Claude Code or Kiro, and another for Codex. Even when those packages contain the same skill instructions or MCP server, the wrapper, discovery rules, and installation steps can differ.

A shared package format gives authors a better lowest common denominator:

Write the reusable workflow as an Agent Skill under skills/.
Describe portable MCP connections once in mcp.json.
Keep client-specific hooks or metadata in a reverse-domain extension namespace.
Let each client own installation, presentation, approvals, and runtime policy.

This is not “write once, run identically everywhere.” It is closer to “package once, then let each client load the pieces it can support.” That is a more modest promise, but it is also the one the specification can plausibly keep.

The security gap is part of the launch story

Agent Plugins gets an important piece of safety right: package paths must remain inside the resolved plugin root, and invalid components should fail in narrow boundaries instead of disabling every valid component in the package. An invalid MCP server entry should not stop a separate skill from loading.

But containment is not sandboxing. The specification explicitly says its path rules do not sandbox a plugin subprocess. A stdio MCP server can still execute code with whatever permissions the host client grants it. A remote MCP endpoint can still access external systems once the client authenticates it. Portability increases distribution; it does not reduce the consequences of installing an untrusted package.

The project’s own future-considerations document lists the gaps: permission declarations, client-enforced capability restrictions, consent flows, cryptographic signatures, provenance, secret injection, enterprise allowlists, audit trails, dependency resolution, and conformance tests. None of those is required for 1.0.0.

That leaves a practical security checklist for teams adopting the format now:

Review the source repository and every script before installation.
Pin the package version or commit instead of pulling an unreviewed moving branch.
Inspect every MCP server command, argument, working directory, remote URL, and header.
Use the client’s native approval, sandbox, and permission controls where they exist.
Treat plugin installation as code execution and external-access approval, not as a harmless prompt import.

Agent Plugins versus OpenAI’s Plugin Directory

There is an easy naming trap here. OpenAI also uses “plugins” for a product layer in ChatGPT and Codex. OpenAI’s Help Center describes those plugins as workflow packages that can include skills, apps, and app templates, with workspace admins controlling availability and underlying app permissions.

Agent Plugins is the lower-level, cross-client packaging standard. It is not a replacement for the Plugin Directory and it does not define a registry. The same ecosystem can have both: an OpenAI or third-party directory can distribute a plugin, while the Agent Plugins format defines the files inside it and the portable behavior a compatible client can discover.

What developers should do next

If you maintain an agent workflow, start with the smallest portable package: a valid plugin.json and one well-scoped skill. Add MCP only when the workflow needs external tools or data. Keep the skill’s instructions specific, testable, and independent of one client’s UI. Then add client extensions only where the portable layer cannot express the behavior.

If you build an agent client, the bar is low enough to be useful. A conformant client can support one component type; it does not have to implement the entire ecosystem on day one. It must load the manifest, validate the version it supports, discover components in fixed locations, and apply the specified failure boundaries. That incremental approach is how the standard can spread without asking every client to become a full clone of every other client.

If you run an engineering organization, do not wait for the format to answer governance questions it intentionally leaves open. Decide which publishers, repositories, transports, and commands your teams may use. Record approvals. Separate read-only tools from write-capable tools. Treat a plugin’s MCP configuration as an access request that deserves the same review as a new developer dependency.

Bottom line

Agent Plugins is a good standard because it refuses to standardize everything. It gives the ecosystem a common package shape, a manifest, predictable discovery, and a portable bridge to Agent Skills and MCP. It leaves marketplaces, UX, authentication, permissions, and trust to the clients that are actually responsible for them.

That makes the launch useful immediately for authors who are tired of maintaining parallel plugin packages. It also makes the security warning immediate: the standard can make a plugin easier to move before it makes that plugin easier to trust. The winners will be the clients and registries that add the missing provenance and approval layers without breaking the small portable core.

FAQ

Is Agent Plugins an OpenAI-only format?

No. OpenAI announced it with several ecosystem partners, and the project describes itself as open and vendor-neutral. The public specification repository and governance documents are hosted under the Agent Plugins project rather than as an OpenAI product repository.

Is Agent Plugins the same as MCP?

No. MCP defines the protocol and lifecycle for tool connections. Agent Plugins defines a package layout and an mcp.json configuration format that clients can map to their MCP runtimes.

Will one plugin behave the same in every client?

No. Clients can support different components and MCP transports, and they retain control over installation, permissions, presentation, authentication, and extensions. Portability means shared packaging and discovery, not identical execution.

Does version 1.0.0 sandbox plugins?

No. The specification contains path-containment rules, but it does not define a permission model or sandboxing requirements for plugin subprocesses. Review and approve plugins as executable code.

Where can I read the standard?

Start with the Agent Plugins documentation, then read the normative 1.0.0 specification and the public specification repository.

Sources

Fact-check note: launch availability, client support, and the 1.0.0 specification were checked against the linked primary sources on August 6, 2026. Client behavior and compatibility can change as implementations ship.