Six AI leaders—OpenAI, Microsoft, GitHub, AWS, Vercel, and Anysphere—have jointly released the Agent Plugins 1.0.0 open specification, standardizing the packaging of AI agent plugins. Developers can package their plugins once and deploy them across multiple clients, including Cursor, GitHub Copilot, and Codex. The specification defines structures such as plugin.json manifests, skills, and mcp.json, but only standardizes the packaging layer, leaving core differentiators like hooks and custom agents untouched. Anthropic, the pioneer of the Claude Code plugin system, did not participate in its development, yet its format has been widely adopted. This shift indicates that competition at the foundational level has moved to the battle for plugin ecosystem dominance—where the real contest lies in attracting the most developers.Article author and source: AI New Era
Six giants from the AI industry sat at the same table for the first time.
On August 6, an open specification named Agent Plugins 1.0.0 was officially released.
It accomplishes a long-awaited goal for countless AI developers: establishing a standardized “package” for AI agent plugins, so that a single package can work across all platforms, eliminating the need to repack for each individual client.
OpenAI developers posted on official Twitter: "Package once, use everywhere across all compatible agent clients," and tagged a series of collaborators.
This specification may seem unassuming, but it hits the pain point right on the nose.
The same skill (Skill) and MCP server (MCP Server) have identical cores, yet you must repackage them individually for Cursor, GitHub Copilot, Codex, and others: whenever one updates, you have to manually update each one separately.
Agent Plugins aims to eliminate exactly this kind of repetitive work.
Standardize the directory structure, manifest file, and MCP configuration format. Package them together so that any client supporting this format can recognize them.
How Agent Plugins Work: Individual skills and MCP on the left are packaged into the plugin.json "box" in the center, then redistributed to various clients such as IDEs, CLIs, and enterprise endpoints.
For example.
You built a plugin for “querying databases and writing weekly reports,” with one skill teaching the AI to organize query results into weekly reports that the team loves, and an MCP server handling the AI’s connection to the database.
Previously, to make it work across three clients, you had to create three separate packages and make changes three times. Now, you only need to create one package and make the change once.
The list of contributors includes AWS, Anysphere (parent company of Cursor), GitHub, Microsoft, OpenAI, and Vercel, and even Google was added as a core maintainer on the day of the release.
Missing only the pioneer of this gameplay—Anthropic.
What is unified is the "package box," not the agent.
A plugin typically consists of two components.
One is Agent Skills, providing reusable instructions and resources for the model; the other is the MCP Server, responsible for connecting to external tools and services.
These two items can already be reused across clients.
The real bottleneck is at the outermost layer: each client has different directory structures, manifest files, and MCP configuration formats, so when the same component is moved to a different client, it must be repackaged according to the new client’s rules.
Agent Plugins standardize the outer packaging layer.
A plugin is a folder.
Place a plugin.json manifest in the root directory, put all skills into skills/, and write the MCP configuration into mcp.json.
Only the $schema and name fields are required in the list; everything else is determined by fixed positions—clients don’t need to guess, not even the version number.
As for any proprietary elements each party wants to include—such as their own unique hooks, commands, or interfaces—place them all in a directory named using a reverse domain name.
Other clients don’t recognize this directory and will simply skip it if encountered. Since it’s at the public level, it’s cleaner, smaller, and easy to implement.
And it regulates very little.
1.0 recognizes only two types of portable components: skills under the skills/ directory and MCP configurations in mcp.json.
Hooks, slash commands, and custom agents are still proprietary to each platform and have not been standardized.
The main text is still labeled as a "Working Draft," as if the official team is quietly adding, "Still in progress," indicating there's still a way to go before it becomes a mature, industry-approved standard.
One sentence: Agent Skills handle instructions, MCP manages tool connections, and Agent Plugins package both together.
Only the packaging box is uniform; the agents inside remain unchanged.
Pack once, not run everywhere.
Even though the packaging is standardized, the operations are still far from being unified.
It only manages the wrappers for the two types of components: skills and mcp.json. Once it comes to actual execution, it steps away:
Installation, distribution, permissions, sandboxing, authentication, trust verification, and user experience—all are left entirely to each client to handle.Support for these transmission methods—stdio, Streamable HTTP, and legacy HTTP+SSE—varies across platforms. Whether the same plugin runs smoothly on a different client depends on luck.
Microsoft also specifically emphasized security: the MCP Server and hooks in the plugin will execute code on your local machine—always verify the source and author before installing, and be especially cautious with items from the community marketplace.
OpenAI's own bundled documentation still uses the .codex-plugin/plugin.json structure, which is not the same as the plugin.json in the open specification root directory.
Compliance only ensures that compatible clients can discover the portable components they support; in practice, authentication methods and runtime environments may still differ.
Therefore, packaging uniformly does not mean execution is also unified—there is an entire engineering pipeline in between.
Ultimately, the layer that was unified is precisely the one the giants care least about letting go of.
None of the truly valuable assets—the app marketplace, permission system, user entry points, or proprietary capabilities like hooks and custom agents—were handed over.
This structure seems so familiar.
People familiar with the Claude Code plugin may have been stunned.
plugin.json, skills, mcp.json—aren't these the same ones Claude Code has been using?
Long before this standard emerged, Anthropic had already built a comprehensive plugin system for Claude Code: a .claude-plugin/plugin.json file at the root directory, along with skills, mcp.json, commands, and agents, plus two official marketplaces for users to share plugins.
The packaging concept of “plugins = skills + MCP + a checklist” was one of the earliest to be successfully implemented by Anthropic, and their approach is even more comprehensive: incorporating skills, hooks, MCP, sub-agents, and slash commands—all bundled together.
This new standard only includes the two universally applicable components: skills and MCP; other more elaborate features were not included.
Interestingly, although Anthropic hasn't joined yet, the format closely resembles its style.
Claude Code already had a root variable pointing to the plugins directory; the new standard adopted it verbatim, only changing the name while preserving its exact function and nearly identical structure.
The compatibility layer can't be hidden anymore.
Microsoft's official VS Code documentation lists anthropics/claude-code as a default plugin in the marketplace.
It supports new open formats while still recognizing Claude format files such as .claude-plugin/plugin.json.
OpenAI’s Codex went even further, deliberately keeping Claude’s original variable name to maintain compatibility with existing Claude plugins.
Others got together and agreed on a format that closely resembles Claude Code, but Anthropic wasn’t there.
The pioneer became an absentee.
A company that pioneered a gameplay model was absent throughout the process as others turned that model into a standard.
But this does not mean Anthropic has been shut out.
Google's two new toolsets both list Claude Code as a compatible target, and it also has two official plugin marketplaces.
More accurately, Anthropic has always preferred to build its own house.
This time, instead of sitting at this unified standard table, it continued to operate its own complete closed loop, from format to market to distribution.
This isn't the first time it has been the most noticeable absence at a "everyone together" event.
Anyone familiar with this company knows that it always refines its own approach to perfection before considering alignment with others.
The benefit is that the product is self-contained with a consistent experience, but the cost is that it often misses out on industry-wide collaborations.
So, why now?
Once the underlying standards are agreed upon, competition will move up a level.
For example, multiple stores can jointly build the foundation of a mall, but once the foundation is set, competition shifts to the shops and shelves above.
That’s now each company’s own domain, where the competition is no longer about which model scores higher, but which has the larger plugin ecosystem and can be the first one developers think of.
Six companies have finalized the box specifications this time.
But what truly determines the winner isn't the box—it's the agent inside; the one who can keep developers loyal will be the victor.