A lot of major names in AI have announced a new open standard called Agent Plugins. The idea is refreshingly simple. It gives developers one portable format for bundling agent skills and MCP servers, so the same plugin can work across multiple AI coding agents.
That matters because AI agent workflows are becoming fragmented. A skill that works well in one coding environment often needs a different structure, a different configuration file, or a separate copy to work somewhere else. Agent Plugins aim to reduce that duplicated effort.
The standard has support across a growing set of products, including GitHub, Kiro, ChatGPT, Codex, Cursor, and VS Code. Google has also joined more recently. There is, however, one significant name absent from the standard: Anthropic.
I wanted to understand what this format actually changes, what moves cleanly between agents, what remains tied to a specific client, and whether it is practical today. I also used the migration tooling from the official example repository to port an Anthropic legal knowledge-work plugin into the Agent Plugin format and install it in Codex.
What Agent Plugins are trying to fix
Most mainstream coding agents already support some kind of plugin system. A plugin extends what an agent can do. It can give an agent reusable instructions, repeatable workflows, specialist knowledge, and connections to external systems.
For example, a plugin might contain a skill for reviewing code, checking accessibility, handling a legal workflow, or preparing a release. It may also connect the agent to an outside service through an MCP server.
The issue is portability. Each AI coding client has developed its own way of packaging and loading these capabilities. A developer can end up maintaining similar resources in several places, even when the underlying task is identical.
Agent Plugins provide a shared folder structure for the parts that can travel between agents. Rather than rebuilding a useful skill for each coding client, the goal is to package it once and make it available across compatible tools.
This doesn’t mean every part of an agent setup suddenly becomes universal. The standard takes a narrower approach. It focuses on the pieces that are practical to standardize right now: skills and MCP servers.
That restraint is important. It keeps the specification relatively small and easy to understand. It also avoids pretending that all AI coding agents behave the same way internally, because they don’t.
A plugin is just a folder
The strongest part of this standard is how little there is to it. An Agent Plugin is simply a directory containing a few predictable files and folders.
The portable core consists of three pieces:
- A skills folder that contains one or more reusable agent skills.
- A plugin.json file that acts as a simple manifest for the plugin.
- An mcp.json file that stores MCP server configuration.
That is the central model. A plugin combines a collection of skills with optional service integrations. The skills define useful ways of working. MCP servers let the agent interact with external services where that plugin needs them.
If you have already written skills for an AI coding agent, this should feel familiar. The skills folder is where the useful, reusable instructions live. The Agent Plugin format gives those skills a portable home alongside a basic plugin manifest and MCP configuration.
The plugin.json file provides the identifying information for the plugin. It tells a compatible client what the plugin is. The mcp.json file provides the MCP server details that allow the plugin to access external services.
The structure is deliberately much simpler than many people might expect from a standard supported by so many large companies. It is not trying to create one huge universal configuration layer for every AI agent. Instead, it creates a common package for the most transferable parts.
The official Agent Plugins specification lays out this portable format in more detail. The key point is that the folder itself is the package. It is not an abstract concept or a special hosted service. It is a simple, inspectable set of files.
Why a simple folder structure matters
Simple formats have a better chance of spreading. A developer can inspect the directory, understand where the instructions sit, identify the available integrations, and see what is being packaged.
It also creates a clearer path for plugin authors. If they build a useful set of skills, they can place them in a standard structure and potentially publish the same plugin in several compatible ecosystems.
That could reduce the need to repeatedly recreate the same specialist workflow for Codex, Cursor, ChatGPT, GitHub Copilot, Kiro, and VS Code. The promise is not that every experience becomes identical. The promise is that the core work can move between those tools with fewer changes.
What travels between agents and what stays client-specific
This is the part to be clear-eyed about. Agent Plugins standardize two things: skills and MCP servers. They do not standardize every feature that people use inside an AI coding environment.
The portable core includes:
- Skills, which provide reusable task instructions and workflows.
- MCP servers, which provide connections to external tools and services.
Everything else remains specific to the client that supports it. That can include commands, hooks, agents, rules, and LSP servers. Those resources do not form part of the main portable standard.
Instead, a client can add its own behavior through a client-specific, namespaced folder. That lets a coding agent support its own features without changing the shared core of the plugin.
For instance, one coding client might support hooks that run at a particular moment in a workflow. Another may have its own command format, rules system, or way to define sub-agents. Those features may be valuable, but they are still too different from client to client to package cleanly into one shared format.
This is likely to be the biggest criticism of the specification. Much of what makes a coding agent feel powerful can sit outside the portable layer. A plugin may carry the skills and MCP connections, but a more advanced setup can still need agent-specific configuration.
At the same time, that limitation is reasonable. Forcing every client into a single format for hooks, commands, rules, and language-server integrations could produce a much heavier standard that none of the tools implement cleanly.
The standard therefore makes a trade-off:
- It gives developers a portable core for common reusable capabilities.
- It allows individual clients to preserve their own distinctive features.
- It accepts that full portability is not possible yet.
That is a more realistic starting point than claiming that every agent feature can transfer perfectly. Skills and MCP are already useful building blocks. Standardizing them can remove meaningful duplication even if client-specific behavior still exists.
Which AI agents support Agent Plugins?
The list of compatible clients is already broad. At the time of this overview, the standard supports GitHub, Kiro, ChatGPT, Codex, Cursor, and VS Code. Google has joined the standard as well.
That range is why the announcement is notable. It is not a format tied to one vendor or one editor. It has momentum from several major players across coding assistants and AI platforms.
There is also an Agent Plugins package in the package catalog for the PI coding agent. I have not used that package myself, so it is worth checking its documentation carefully before relying on it in a project.
The most current support list is available on the compatible clients page. Compatibility still needs some nuance. A client may support the shared plugin format while also having its own installation flow and its own features outside the portable core.
Anthropic is the major exception. Anthropic is not a maintainer of the standard, Claude Code is not a launch client, and the company has not publicly joined this initiative.
That absence creates an interesting split. Anthropic has its own plugin ecosystem and popular knowledge-work plugins. Yet those plugins do not automatically arrive in the new portable format. They may need migration work before they can run through the Agent Plugin standard in other clients.
How I migrated an Anthropic legal plugin to Agent Plugins
To test the format properly, I used the migration skill from the official Agent Plugins example repository. That repository comes from the maintainers of the specification and includes an example skill for migrating existing Claude, Copilot, Codex, and Cursor-specific plugins into the portable Agent Plugin format.
I selected the migration plugin and gave Codex Anthropic’s legal knowledge-work plugin as the source. Anthropic has published a collection of these knowledge-work plugins on GitHub, including a legal plugin with a set of specialist skills.
The basic process was straightforward:
- I opened the migration skill from the Agent Plugins example repository.
- I pointed it at Anthropic’s legal knowledge-work plugin.
- I let Codex process the plugin and convert it into the new structure.
- I checked the resulting files to make sure the portable core existed.
- I refreshed the Codex plugin interface and installed the migrated legal plugin.
After a few minutes, the conversion had produced the expected structure. The result included a plugin.json file, an mcp.json file, and the relevant skills.
This is a useful demonstration of what the standard can offer. An existing, agent-specific plugin does not necessarily have to stay confined to its original environment. Where its useful parts fit the portable model, a migration skill can reorganize it into a format that another compatible client can use.
The source migration tooling is available in the Agent Plugins example repository. The original legal source used for this test is part of Anthropic’s legal knowledge-work plugins.
Installing the migrated plugin in Codex
Once the migration finished, I opened the plugins area in Codex and refreshed it. The new legal agent plugin appeared in the list. Opening it showed its skills and MCP servers.
Installing it also showed an important practical detail. Because the plugin contained MCP servers, Codex prompted for sign-in. That makes sense. MCP integrations can connect an agent to outside systems, so authentication may be necessary before the relevant service can be used.
I skipped the sign-in step at that moment, but the installation itself succeeded. I could then move into a completely different project, open the skill selector, type “legal,” and see the migrated skills available there.
One of the available options was a compliance check. Selecting it brought up the skill in the new project. That is the portability story in a practical form: a legal workflow from Anthropic’s plugin ecosystem had been migrated and then made available inside Codex.
The test did not prove that every plugin from every system will migrate perfectly. Client-specific instructions, commands, and hooks may still need separate treatment. But it did show that the core skill and MCP model can transfer in a useful way.
The awkward part: installation and local loading
The folder format is portable. Installing the folder locally is a different matter.
I initially ran into problems trying to install these plugins directly from my machine. Codex and Cursor both expect plugins to arrive through marketplaces. That makes the experience less portable than simply dropping a skill into a project folder.
If a developer uploads an Agent Plugin to an online marketplace for a coding agent, installation should be relatively seamless for people using that marketplace. The same developer could then upload that plugin to other compatible marketplaces, potentially with few changes or no changes at all.
That is useful, but it is not the same as universal local loading. The current standard defines the portable structure of the plugin itself. It does not define a universal way to distribute, discover, or load those plugins.
For my local setup, I had to get Codex to create a marketplace.json file and point Codex to the location where it could find the plugins. It worked, but it was not ideal.
This distinction is worth keeping in mind:
- The standard defines the package. Skills, a manifest, and MCP configuration can move in a common folder structure.
- The client controls installation. Each coding agent can still decide how it finds, approves, installs, and manages plugins.
- Marketplaces are separate from the portable core. A plugin may be portable while its distribution process remains tied to each platform.
This is why Agent Plugins do not yet feel as frictionless as loading an individual skill into a project. In many cases, a skill file can be added directly to the project setup. A plugin may instead need marketplace configuration, a refresh process, or other client-specific steps.
That does not make the standard a bad idea. It simply means the portability promise has boundaries. The standard makes the plugin contents portable. It does not solve every operational detail around how those contents reach an AI agent.
Over time, distribution could become smoother if compatible clients improve local loading and marketplace support. Right now, the developer experience still depends heavily on the client being used.
Plugin security still matters
Agent Plugins package instructions and can include MCP server integrations. That means the usual safety considerations apply.
I would only use externally sourced plugins from reputable sources or plugins whose contents I understand well. The same caution applies to agent skills and MCP servers generally.
A useful plugin can give an AI agent access to workflows and external tools. That is exactly why it can be valuable. It is also why it deserves inspection before installation.
At a minimum, check the following:
- Who published the plugin and whether the source is credible.
- What skills and instructions the plugin contains.
- Whether it includes MCP servers or requires external authentication.
- Which services the MCP configuration may connect to.
- Whether the plugin behavior is appropriate for the project where it will run.
The new package format does not remove the need for good judgment. Portability makes reuse easier. It should not make blind installation easier.
Why open standards are valuable for AI agents
The long-term question is whether this standard persists. Standards live and die based on adoption. A clean specification is helpful, but broad and sustained support determines whether it becomes part of normal developer workflows.
I think this is a positive move because it gives AI agent users more consistency. It can make it easier to move between coding agents without carrying a growing pile of duplicated files and slightly different plugin formats.
Anyone who has used Claude Code and Codex in the same project will recognise the small but persistent friction. One agent may expect an AGENTS.md file. Claude Code uses CLAUDE.md. You may need separate skill files, or one file that refers to another.
Those differences can create extra work. They can also create redundancy and inconsistency. A workflow updated in one agent configuration may not get updated in the other. Over time, that can cause problems inside a project.
Agent Plugins will not erase every difference between AI coding tools. It does, however, create one shared way to package skills and MCP servers. That is a meaningful place to start.
The standard also appears simple enough to gain wider adoption. It has support from several large names already, and Google joining adds further weight. The format itself is easy to explain: a directory, skills, a manifest, and MCP configuration.
The Anthropic question
Anthropic’s absence is the major variable. If Anthropic adopted this standard, it would greatly strengthen the case for Agent Plugins becoming the shared package format across AI coding agents.
Without Anthropic, there is a real possibility that the ecosystem settles into two formats. Claude Code could continue with its own conventions while the other compatible clients align around Agent Plugins.
That would resemble the current split between CLAUDE.md and AGENTS.md. Developers could still migrate or maintain parallel resources, but the hoped-for consistency would be incomplete.
Even so, the current support makes the standard worth paying attention to. It provides a common language for portable agent skills and MCP integrations across a substantial group of coding tools. It may not cover every feature, every installation path, or every vendor, but it reduces an obvious source of duplication.
What this means for existing skills and plugins
If you already have useful agent skills, they do not need to remain locked to a single coding client. The Agent Plugin format gives them a route into a more portable package.
The first practical step is to separate the transferable pieces from the client-specific pieces. Skills and MCP configuration belong in the portable core. Hooks, commands, rules, agents, and other client-only features should stay in the relevant namespaced configuration for the tools that support them.
A sensible approach is to think in layers:
- Build the reusable skill layer. Keep task instructions clear and useful across different coding environments.
- Add MCP servers where the workflow needs external services. Treat those integrations carefully because they can involve authentication and access.
- Package the shared core as an Agent Plugin. Use the skills folder,
plugin.json, andmcp.json. - Keep advanced agent-specific behavior separate. Do not assume commands, hooks, or rules will transfer between clients.
- Test installation in each target client. The package may travel, but installation and loading can still differ.
That mindset avoids overpromising. Agent Plugins are a portable core, not a complete universal replacement for every AI coding configuration.
The format is still a very encouraging sign. AI agent workflows become more useful as they become reusable. A simple common structure for skills and MCP servers can help developers carry their best workflows across tools instead of rebuilding them repeatedly.
