Source: Google Developers Blog — 2026-08-06

Summary

Google joined OpenAI, AWS, Microsoft-adjacent contributors (GitHub, Anysphere/Cursor) and Vercel — which initiated the proposal — in publishing Agent Plugins 1.0.0, a vendor-neutral open spec for packaging AI agent Skills and MCP servers into a single portable unit any compliant agent client can load. Google joins as a Core Maintainer alongside the other companies. The format is deliberately minimal — a directory containing a manifest, a skills folder, and an optional MCP config — while install mechanisms, distribution, and permission models are intentionally left for each client to implement its own way.

Key Takeaways

• A plugin is a directory with three parts: plugin.json (manifest), a skills/ folder holding packaged platform knowledge (e.g., how to deploy to Railway or query Supabase), and an optional mcp.json for live MCP server access to real infrastructure.
• Co-developed and refined collaboratively by AWS, Anysphere, GitHub, Microsoft, OpenAI, and Vercel, with Google publicly joining as a Core Maintainer of the spec.
• Vercel initiated the original proposal; the finished spec, its JSON Schemas, and separate guides for plugin authors versus client implementers are published at agent-plugins.org.
• The spec deliberately does not define install mechanisms, distribution protocols, or permission models — each vendor/client is free to differentiate on how plugins get installed and what they're allowed to do.
• Goal: let one packaged bundle of skills plus MCP access run across multiple different agent products instead of being rebuilt separately for each platform.

Reel Script

Hook (~18s, ~40 words) Right now, a skill you build for one AI coding agent doesn't work in any other one — you're rebuilding the same integration five times for five different tools. Google just joined OpenAI, Amazon, and Vercel to make that problem go away.

Core Concept (~70s, ~155 words) This is Agent Plugins 1.0 — and to understand why it matters, you need to know the difference between the two things it packages. "Skills" are basically instructions: platform knowledge like "here's how you deploy to Railway" or "here's how you query Supabase," written so an agent can follow them. "MCP servers" are different — they give an agent live, authenticated access to a real system, actual read-write account access, not just instructions. Before this spec, every agent vendor had its own bespoke way of loading skills and connecting MCP servers, so plugin authors had to package the same capability differently for Claude, for Cursor, for whatever agent platform. Agent Plugins standardizes the packaging — not the runtime, not the permissions, just the box the capability ships in — so one plugin can, in theory, load into any compliant client.

Hands-On (~55s, ~125 words) The actual format is almost aggressively simple, which is the point. A plugin is just a folder: a plugin.json manifest describing what it is, a skills/ directory holding the packaged instructions, and an optional mcp.json if the plugin also wants to wire up live server access. That's it — three pieces, one directory. What the spec pointedly leaves out is just as telling: how you install a plugin, how it gets distributed, and what permissions it's granted are all left to each client to decide. Five major companies — AWS, Anysphere, GitHub, Microsoft, OpenAI, Vercel, now Google — agreed on the shape of the box, while keeping the interesting competitive parts open.

Takeaway (~22s, ~50 words) A shared packaging format is unglamorous compared to a new model release, but it's the kind of boring infrastructure that determines whether the agent ecosystem fragments into five incompatible walled gardens or actually composes. Worth watching whether client implementations show up fast. Go skim the spec at agent-plugins.org before you build a plugin the old, locked-in way.

Discussion