As of August 8, 2026, Beijing time, the Agent Plugins official website has designated version 1.0.0 as an open and vendor-neutral standard for agent plugins. Aiera's public report that morning also introduced the specification. It defines a common packaging method for Agent Skills and MCP server configurations, enabling compatible clients to discover components according to a unified directory structure. However, the official specifications page still marks its current status as Working Draft; version 1.0.0 refers only to the format and accompanying Schema versions and should not be interpreted as a frozen or mandatory industry rule.
Maintenance Organization and Scope of Specifications
The project homepage states that core maintainers from the initial technical steering committee come from five organizations: Amazon, Cursor, Microsoft, OpenAI, and Vercel. The specifications, JSON Schema, governance documents, and contribution processes are all available on the official website and public GitHub repository. New features or substantial modifications start with open discussions before being processed through maintenance procedures. This list indicates the sources of committee maintainers but does not represent the number of compatible clients nor provide a complete tally of participating companies or product support levels.
The background provided in the official documents explains that different AI agent clients previously developed their own plugin formats, leading to authors needing to rearrange or duplicate directories even when plugins contained identical components. Agent Plugins aims to establish a limited interoperability foundation for shared parts using predictable structures. This core does not unify plugin distribution, installation, permissions, or user experience; these aspects remain decided by individual clients. Client-specific capabilities can continue to exist and are not part of the 1.0.0 universal semantics.
Directory Structure and Component Discovery
A compliant plugin is rooted in a single file system directory, which must contain plugin.json. The skills directory and mcp.json respectively carry the skills and MCP server configurations but can both be omitted; the absence of optional locations themselves does not constitute an error. Client-specific manifest data can be placed under reverse domain name namespaces within the extensions field, with related files located in a top-level directory of the same name. There is only one core manifest that cannot be replaced, supplemented, or overridden by other files for its general fields.
Version 1.0.0 defines only two core components: Agent Skills and MCP server. Skills are found from SKILL.md within direct subdirectories of the skills directory, while MCP configuration is read solely from mcp.json in the root directory; plugin.json cannot alter these fixed locations. Clients can adopt features incrementally, supporting either just skills or just the MCP server to meet minimum requirements, but at least one component type must be supported. Unimplemented components should be ignored, and a single invalid component should not prevent other independent and valid components from continuing to load.
Connection Configuration and Security Boundaries
The mcp.json file can describe connections for stdio, Streamable HTTP, or legacy HTTP with SSE. Clients are not required to implement all transmission methods simultaneously. If a client starts a stdio subprocess, the specification requires it to provide PLUGIN_ROOT and PLUGIN_DATA, expanding these placeholders only in specified fields such as parameters, environment values, and working directory. The PLUGIN_DATA is used for a data directory managed by the client that can be preserved across updates. Additionally, the specification clarifies that env is visible package configuration and not a portable secret mechanism; plugins should not write credentials to it.
For files within plugin packages, the specification requires that parsed paths remain within the plugin root directory, with out-of-bound paths being rejected according to their corresponding failure scope. Invalid skills, MCP server entries, or component types are handled separately to avoid affecting other valid parts. This constraint applies only to files provided by plugins and does not automatically restrict the paths a subprocess can access during runtime; official text explicitly states that it does not constitute a sandbox for subprocesses. Permissions for plugin installation, run-time authorization, and basic environment cleanup are also not standardized and remain the responsibility of specific clients.
Compatibility List and Timeline
The official compatibility page currently lists five client entries: VS Code, Cursor, GitHub Copilot, ChatGPT with Codex, and Kiro. Each entry is marked for skills, MCP, and transport support, allowing products to adopt these features progressively. Aiera's headline uses the term 'six giants' as a summary, but the public short summary does not list six names or specify the criteria; official materials can verify five committee-maintainer source organizations and five client entries, with different scopes that do not allow for identifying a sixth entity or inferring Anthropic's position.
The timeline in the open repository also corrects the dates mentioned in the report: the commit publishing version 1.0.0 occurred on July 24 and was merged on July 27; verifiable changes on August 6 include modifications to the homepage and code changes describing the project as an open standard; Aiera's report entered this round's discovery window on August 8. Existing materials do not disclose the number of installed plugins, cross-client adoption rates, migration costs, or independent security audits, nor do they confirm that all client functionalities and permission models are entirely consistent. Subsequent developments should be assessed against the draft status, versioned Schema, and public governance records.