Google joins Agent Plugins spec as core maintainer, backing vendor-neutral standard for AI agent tools

Google has become a core maintainer of the Agent Plugins 1.0.0 specification, joining Amazon, Cursor, Microsoft, OpenAI, and Vercel in standardizing how developers package and distribute skills and Model Context Protocol (MCP) servers for AI agents.

The packaging problem#

The challenge Agent Plugins addresses is straightforward: when developers build a reusable agent skill alongside supporting tools and scripts, they face fragmentation across different AI platforms. The same underlying component—say, code that queries a database and generates a weekly report—requires different directory structures, manifest formats, and MCP configurations for each client. This forces developers to maintain multiple versions of essentially identical packages, watching them gradually diverge over time.

The root issue isn't the skills or tools themselves; both are already portable. It's the wrapper around them—the manifest and directory structure each client historically invented for itself.

How Agent Plugins work#

The specification keeps things deliberately simple. A plugin is just a directory with a minimal manifest:

• A plugin.json file with a schema reference and name
• A skills/ directory containing reusable instructions and resources in the format Agent Skills already defines
• An mcp.json file declaring tool connections with explicit transport types
• Optional client-specific extension directories (using reverse-domain naming) for hooks and features unique to one platform

The fixed layout means clients never need to guess how components are organized or configured. If a skill fails to load, the rest of the plugin continues working. MCP servers explicitly declare whether they run on stdio, HTTP, or HTTP+SSE—no inference required.

Why scope matters#

Agent Plugins deliberately omits several functions beyond packaging: installation mechanisms, distribution protocols, permission models, sandboxing, and trust verification. That's intentional. Those concerns differ significantly across different environments—an IDE, a command-line tool, and an enterprise platform each have distinct security and approval needs. Keeping the spec focused on packaging allows each platform to handle distribution and policy independently.