Google is joining the Technical Steering Committee of Agent Plugins, a new specification that bundles an AI agent’s skill instructions with the servers that provide MCP, Anthropic’s protocol for tool calling, as a Core Maintainer. Google Cloud Tech laid out the mechanics in a long-form post on X, credited to Google Cloud developer relations engineer @lavinigam, arguing the spec gives every agent client one folder to read instead of a different bundle per tool. The specification itself carries a Working Draft label, not a ratified standard, and the loudest voice pushing adoption now belongs to one of the largest vendors in the ecosystem.
Agent Plugins addresses a real gap. A skill’s instructions lived in SKILL.md while the tool it called lived in a separate MCP server, and nothing bound the two beyond whatever a README told a developer to copy by hand into each client. The new spec fixes that with a single root file, plugin.json, that needs only two required fields to load in test mode. A closed schema caps the file at ten total fields, and only two kinds of mistakes get forgiven: an unrecognized top-level key and a malformed extensions block. Everything else, including a wrong data type on an optional field, causes the client to reject the whole package.
Nesting breaks discovery. A client only scans the top-level folders inside skills, never recursing, so a library already sorted into category subfolders quietly stops loading once packaged, with nothing explaining why. Tool dependencies live in a second file, mcp.json, which supports three transport types: stdio, streamable-http and the optional sse. Two environment placeholders control where a bundled process writes, and the distinction is easy to miss: anything saved under PLUGIN_ROOT vanishes the next time the plugin updates, while PLUGIN_DATA is meant to persist.
Failure is scoped by design. If an MCP server refuses to start, the client must keep loading every other skill rather than treating the whole folder as broken, making this a package format rather than an all-or-nothing bundle. A separate namespace lets each client store its own extensions, for hooks, commands or subagents that never made it into version 1, without those additions breaking any other client’s copy of the same plugin. That flexibility cuts both ways. Should each client end up favouring its private namespace over the common core, plugins could re-fragment exactly the way tool bundling did before the spec existed.
The unresolved piece is authentication, and it is unresolved by design, not oversight. The specification bars plugins from embedding credentials in their files, which is reasonable since anyone who downloads a plugin can read every header inside it. Version 1.0.0 defines no portable field for referencing a credential either, so a skill sitting behind an authenticated API still needs separate setup in every client that runs it. That is not a small gap. The distribution problem Agent Plugins solves, getting instructions and tools into one folder, is the easy half of running an agent against real systems. The hard half is proving to a database, a payments API or an internal tool that the agent is allowed to act, and that half still lives outside the folder, negotiated client by client the same way it was before.
Two Google products already ship in this format: Agents CLI, which packages Google’s own skills for building, evaluating and deploying agents, and the Data Agent Kit, which bundles Spanner, Cloud SQL and AlloyDB connectors alongside a BigQuery starter pack. That is real but early use, not evidence of broad adoption; the post points to a growing list of compatible clients at agent-plugins.org without saying how many teams outside Google have shipped one. The spec is described as vendor-neutral and governed by an open committee, but the account explaining it, the products using it and the newest Core Maintainer all belong to the same company. A standard can be neutral in design and still get shaped first by whoever ships the reference implementations.
For a team already juggling a different plugin format per client, Agent Plugins removes real duplication: one manifest, one tool declaration file, one skills folder, read the same way by every client that adopts the spec. It does not replace what already exists. Claude Code still reads its own .claude-plugin/plugin.json and .mcp.json, and Antigravity still reads mcp_config.json, so a repository built today likely carries both formats until more clients converge. Budget the migration as two separate pieces of work: rebuilding the folder structure, which this spec makes close to mechanical, and building the client-specific credential handling that the folder still cannot carry.
Teams standardizing their skill libraries should adopt the folder shape now, since it costs little. They should not treat Agent Plugins as an authentication story: the credential architecture still has to be designed and wired per client, exactly as before.
Google Cloud Tech, writing on X, published this post on August 13, 2026, credited to Google Cloud developer relations engineer @lavinigam.
