Agent Plugins 1.0.0 attempts to solve a specific problem in the agent ecosystem: the same set of capabilities may need to be reorganized or adapted to work on different clients. The proposal is to establish a common core to package these capabilities, so that compatible clients know where to find them and how to interpret the basic configuration.
This core, however, is deliberately limited. The format does not create a universal installation system, defines who to trust, establishes permissions, or determines how a plugin should be isolated during execution. These decisions remain the responsibility of each product that implements the specification.
There is also an important nuance in chronology. The official repository history records the publication of specification 1.0.0 on July 24, 2026. On August 6, 2026, a new change began to explicitly describe Agent Plugins as an “open standard”. Therefore, August 6 serves as a public milestone for this characterization, but it was not the first publication of version 1.0.0.
The documentation consulted on August 7 presents 1.0.0 as the current published version, while the normative text itself still has the status Working Draft. This does not prevent the version from being used as an interoperability contract: the specification determines that identifiers from previously published schemas cannot be reused with different content, and changes to these schemas require a new version of the specification.
What Agent Plugins 1.0.0 actually standardizes
The basic unit is simple: a plugin is a self-contained directory, with a required plugin.json file at the root. Version 1 defines only two types of portable components: Agent Skills and MCP servers. Skills are located in a skills/ directory; the MCP configuration is in mcp.json.
The plugin.json works as the package manifest. Among other information, it identifies the specification schema and the name of the plugin. The format uses a closed schema: client-specific extensions must not create arbitrary fields at the main level, but can live within their own namespace in extensions. You can also reserve a top-level directory for these particular resources.
This choice creates a useful separation between what is intended to be portable and what remains belonging to each platform.
| Layer | Does 1.0.0 standardize? | Treatment |
|---|---|---|
| Plugin manifesto | Yes | plugin.json in the root |
| Agent Skills | Yes | Discovery in skills/, using the Agent Skills specification |
| MCP Server Configuration | Yes | mcp.json with common format |
| MCP Transport | Partially | stdio, Streamable HTTP and legacy SSE are described |
| Client-specific extensions | Just isolation | Own namespace; behavior is defined by the customer |
| Installation and marketplaces | No | Customer responsibility |
| Permissions, trust and sandbox | No | Customer responsibility |
| Interface and user experience | No | Customer responsibility |
MCP standardization deserves attention because Agent Plugins do not replace the Model Context Protocol. The MCP continues to define the protocol and its lifecycle; Agent Plugins defines how the configuration of an MCP server is packaged within a portable plugin.
In 1.0.0, an MCP entry can declare stdio, streamable-http, or the legacy SSE transport. A client with MCP support must implement at least one of stdio and Streamable HTTP, and is not required to support all transports. This already shows an important limit to the promise of portability: two clients can be compatible with Agent Plugins and still offer different sets of capabilities.
Portability does not mean identical execution on any client
The specification allows for incremental adoption. A client can be considered compliant by only supporting Skills, without implementing MCP servers. Components that it does not understand should be ignored, without necessarily invalidating the rest of the plugin. Failures in an MCP server must also not render independent components that remain valid unusable.
As of August 7, 2026, the official compatibility page lists VS Code, Cursor, GitHub Copilot, ChatGPT & Codex, and Kiro. They all appear with Agent Skills support, but there is a difference in the set of MCP transports reported: ChatGPT & Codex, for example, appear with stdio and Streamable HTTP, while other clients listed also indicate support for legacy SSE. This relationship is changeable and must be checked before assuming compatibility in production.
Thus, “packaging once” does not automatically equate to “having exactly the same behavior in any tool”. The gain is in eliminating part of the structural adaptation: the client knows how to look for the manifest, Skills and MCP configuration in predictable places and can reuse what it supports.
Features such as proprietary commands, hooks, custom agents, rules, and LSP servers remain outside of the v1 portable component types. The project's own justification says that these formats are still too specific to each client to integrate into the stable core.
Border security is especially important
Agent Plugins 1.0.0 includes some defensive packaging rules. Paths provided by the package must remain within the plugin root, and clients must reject certain attempts to escape this limit. Configuring a local MCP process also separates the package directory from a persistent area administered by the customer, through PLUGIN_ROOT and PLUGIN_DATA.
This, however, is not an execution sandbox. The specification itself clarifies that its path containment rules do not restrict everything that a subprocess executed by the plugin can access during its operation.
The project is equally explicit about what remains without a portable solution in 1.0.0. The future considerations document notes that the version does not define:
- trust model, permission system or sandboxing requirements;
- cryptographic verification of origin and integrity of plugins;
- common mechanism for storing, providing, or limiting secrets;
- corporate allowlist, blocklist and approval policies;
- standardized format for audit events;
- dependencies between plugins;
- common plugin testing or validation tool.
There are limitations even within the MCP configuration. Credentials should not be embedded in fields like headers or env, but 1.0.0 also does not provide a portable credential referencing mechanism or universal OAuth configuration. Authorization discovery, user interaction, and credential storage are under the control of the customer.
This distinction avoids a dangerous reading of the advertisement: a plugin that obeys the format is, therefore, not a reliable or safe plugin to run. Packaging compliance and trust decision are different problems.
Why such a small pattern can be useful
Agent Plugins attempts to establish a “floor” of interoperability, not transform all agents into a single platform. The official website starts from the observation that customers have created their own formats even when loading similar components. The effect for authors is to duplicate structure and adaptation between tools.
The chosen solution is to keep the core small: predictable directories, versioned manifest, Skills, MCP configuration, loading rules, some guarantees about paths and a mechanism to isolate particular extensions.
This also explains why the standard doesn't try to decide how a marketplace should work or what approval window should appear before execution. If it incorporated these decisions into the core, it would have to juggle very different product, security and distribution models.
For a team that produces plugins, the potential benefit is being able to maintain the common part once and add extensions only where a customer requires specific behavior. For a client implementer, there is a minimum discovery and validation contract rather than relying on each vendor's particular conventions.
“Open and neutral” is also about governance
The project officially presents itself as an open and vendor-neutral standard. The documentation and specification text are developed publicly, and the charter states that the project exists to promote portability, competition, and stability across platforms.
Governance further determines which positions are held by individuals and that no one vendor can control the majority of Core Maintainer positions. In the composition published on August 7, members of the Technical Steering Committee have affiliations with Amazon, Cursor, Microsoft, OpenAI and Vercel.
Specification text and documentation are licensed by default under CC BY 4.0, while code uses Apache 2.0, unless future decisions are made in the charter.
This model reduces the format's association with a single product, but does not alone guarantee broad adoption or complete compatibility. The outcome will depend on how many customers implement the core, which components they support, and how much behavior remains tied to platform-specific extensions.
What to check before adopting Agent Plugins
To evaluate the portability of a real plugin, the most useful question is not just “does the client support Agent Plugins?”. You need to check which parts it implements.
Before depending on the format, it makes sense to check:
- whether the flow uses only Agent Skills or also requires MCP servers;
- which MCP transports are available on the destination client;
- if there are hooks, commands, agents or other functions outside the portable core;
- how the customer installs, updates and uninstalls plugins;
- what permissions, approvals and isolation mechanisms does it apply;
- how origin, integrity and credentials are verified;
- what administrative controls exist in the environment in which the plugin will be run.
Agent Plugins 1.0.0 reduces a real layer of fragmentation, but does not eliminate differences between runtimes. Its role is more precise: to define how shareable capabilities are packaged and discovered, deliberately leaving operational security, distribution, and execution experience to the platforms carrying the package.
To track changes, the safest reference is the official specification, the repository's versioned history, and the supported clients page — especially while the regulatory document remains marked as Working Draft.
