Agent Plugins 1.0.0 is a vendor neutral packaging format for agent extensions, and Google joined its Technical Steering Committee as a core maintainer on August 6, alongside Amazon, Cursor, Microsoft, OpenAI and Vercel. The problem it targets is dull and real: a skill or an MCP server written for one agent client had to be rewritten to ship in another. The spec answers with a directory, a two field manifest and fixed locations for components. Five clients supported it at launch. What the spec deliberately leaves out is as interesting as what it defines, so we read it and mapped both.
The short answer
Agent Plugins 1.0.0 defines a shared directory format for packaging Agent Skills and MCP servers so a compatible client can discover and load them consistently. A plugin is a folder holding plugin.json, an optional skills directory, an optional mcp.json declaring MCP servers over stdio, Streamable HTTP or legacy HTTP with SSE, and reverse domain namespaced folders for client specific data. Google joined the Technical Steering Committee as a core maintainer on August 6, 2026, alongside Amazon, Cursor, Microsoft, OpenAI and Vercel. Installation, distribution, permissions and sandboxing are explicitly outside the scope of version 1.0, which leaves those decisions with each client.
Most standards announcements are worth skimming and forgetting. This one earns a closer look for an unglamorous reason: it does very little, on purpose, and the little it does is the part that six competing vendors could actually agree on.
The duplication it removes
Agent Skills and MCP servers both already existed as open specifications with real adoption. Nobody was short of ways to give an agent a tool or a procedure. What was missing was a shared answer to a smaller question: where do those things live on disk, and how does a client find them.
In practice that meant an extension written for one client had to be reshaped for the next. Same skill text, same server binary, different wrapper, different manifest fields, different expectations about folder names. Teams maintaining anything used in more than one place ended up maintaining variants that differed only in packaging.
Agent Plugins 1.0.0 replaces that with one layout. The client scans the directory rather than interrogating a manifest. If a skills folder is present, skills load. If an MCP configuration is present, servers connect. The manifest itself is close to empty by design, requiring only a schema reference and a name.
What a plugin looks like
The shape is deliberately boring. A plugin root holds plugin.json. Skills sit under a skills directory, each in its own folder with the familiar arrangement of a SKILL.md and whatever scripts and reference files it needs. MCP servers are declared in mcp.json, with the transport named explicitly: stdio, Streamable HTTP, or the older HTTP with SSE approach that is still in the field.
The escape hatch is a reverse domain namespace. A client that needs to store something of its own does it in a folder named after itself, which keeps client specific data out of the shared contract without forbidding it. That is the mechanism that lets clients keep innovating without every addition becoming a standards negotiation.
What it does not do
This is the part to read carefully before you plan anything around it. The specification does not cover installation. It does not cover distribution. It does not cover permissions, sandboxing, or trust verification. Those omissions are stated, not overlooked.
That scope is defensible. Getting Amazon, Cursor, Microsoft, OpenAI, Vercel and now Google to agree on a directory layout is a solvable problem. Getting the same group to agree on a permission model is a much harder one, and a specification that attempted both would likely still be in draft.
The practical consequence for a team is easy to state. The format gives you portability of authoring: write the skill once, keep one copy, ship it anywhere that implements the spec. It gives you nothing at all about where plugins come from or what they may touch once loaded. Those answers still come from whichever client you run, on that client's terms, and they will differ between clients for the foreseeable future.
Who is shipping it
Five clients supported the format at launch: ChatGPT and Codex, Cursor, GitHub Copilot, Kiro and VS Code.
The toolkit side is where the intent shows. AWS publishes the AWS Agent Toolkit as plugins, described as more than thirty curated skills spread across several packages for its services, with Kiro consuming installable packages through its Powers mechanism. Google, on joining as a core maintainer represented by Kevin Hou of Google DeepMind, published an Agents CLI packaging its own guidance for building, evaluating, deploying and observing agents, plus a Data Agent Kit that connects to BigQuery, Spanner, Cloud SQL and other Google Data Cloud services.
Google's stated intent is that these work with any AI coding agent rather than only Google clients. That is the right thing to say, and it is the claim to check against the next few releases rather than accept on announcement day.
Whether to move now
If you maintain skills or MCP servers consumed by more than one client, the conversion is mostly file moving and is worth doing this week. The skill content does not change, the server does not change, and you gain a single canonical copy.
If everything you have is consumed by exactly one client and that is not going to change, there is no urgency, and being early to a 1.0 mainly means finding its rough edges yourself.
The common middle case is two or three internal tools, one client today, and a plausible second client within the year. Packaging to the spec there costs an afternoon and saves a migration, which is about as clear as a build versus wait decision ever gets.
Sources and further reading
- Agent Plugins specification, agent-plugins.org
- Agent Plugins Specification v1.0.0 on GitHub
- Introducing Agent Plugins, Vercel, August 6, 2026
- AWS Supports Agent Plugins, AWS Open Source Blog, August 6, 2026
- Agent Plugins package your skills, tools, and more, Google Developers Blog, August 6, 2026
Frequently asked questions
What problem does Agent Plugins actually solve?
Duplication of packaging work, not capability. Agent Skills and MCP servers already had open specifications and real adoption before this, so the components themselves were never the blocker. The blocker was that every agent client expected those components laid out its own way, with its own manifest fields and its own directory conventions, which meant that shipping the same skill to two clients meant maintaining two packages that differed only in their wrapper. Agent Plugins defines one predictable layout that a compatible client can scan: if a skills directory exists, load the skills, if an MCP configuration is present, connect the servers. Author once, ship anywhere that implements the spec. It is the same move that package formats and container images made in their own eras, applied to a much younger ecosystem, and its value comes almost entirely from how many clients agree to read it rather than from any technical cleverness in the format.
What is inside a plugin, concretely?
A directory. At its root sits plugin.json, and the required content of that file is unusually small: a schema reference and a name. Everything else is expressed through the file structure rather than declared in the manifest. A skills directory holds Agent Skills, each in its own folder with the familiar shape of a SKILL.md file plus optional scripts and reference material. An mcp.json file declares MCP servers, with the transport stated explicitly, which can be stdio, Streamable HTTP, or the legacy HTTP with SSE arrangement. Alongside those, a client is free to add its own directory named with a reverse domain namespace, which is where client specific configuration lives without polluting the shared contract. The design choice worth noticing is that discovery is structural. A client does not need the manifest to tell it what is present, it looks.
What does the specification deliberately not cover?
Installation, distribution, permissions, sandboxing and trust verification are all out of scope for 1.0, and this is stated rather than accidental. The result is a format that tells a client how to read a plugin and says nothing about how the plugin got there or what it is allowed to do once loaded. That is a defensible scope decision, because agreeing on a layout is achievable across six competing vendors while agreeing on a permission model is not, and a spec that tried to do both would probably have shipped neither. It does mean that the interesting questions move up a level to each client. If you are evaluating this for a team, the format buys you portability of authoring, and every question about where plugins come from and what they can touch is still answered by whichever client you run, on that client's terms.
Which clients and toolkits support it today?
Five clients supported the format at launch: ChatGPT and Codex, Cursor, GitHub Copilot, Kiro, and VS Code. On the toolkit side, AWS ships the AWS Agent Toolkit as plugins, described as more than thirty curated skills spread across several plugins covering AWS services, and Kiro consumes installable packages through its Powers mechanism. Google, on joining as a core maintainer, published two of its own: an Agents CLI that packages its guidance for building, evaluating, deploying and observing agents, and a Data Agent Kit that connects to BigQuery, Spanner, Cloud SQL and other Google Data Cloud services. Google's framing is worth quoting for its intent, that these are meant to work with any AI coding agent rather than only with Google clients. Whether that holds in practice is the thing to watch over the next few releases.
Should I repackage my existing skills and MCP servers now?
If you maintain something used by more than one client, yes, because the conversion is mostly moving files. Your SKILL.md content does not change, your MCP server does not change, and what you are adding is a manifest with two required fields and a directory arrangement. If everything you have is consumed by exactly one client and you have no plans to change that, the honest answer is that there is no urgency, and adopting a 1.0 specification early mainly buys you the chance to discover its rough edges on your own time. The middle case is the common one: you have two or three internal tools, one client today, and a decent chance of a second client within a year. There, packaging to the spec now is cheap insurance, and it costs you an afternoon rather than a migration.