Agent Plugins is an open format for packaging extensions to AI agents. It does not replace tool protocols or skill files. Instead, it puts Agent Skills and MCP server configuration into a directory with a shared manifest, so compatible clients can identify what the package contains, which environment variables it needs, and how its components should be loaded.
The One-Sentence Definition
Agent Plugins is a portable installation package for agent capabilities: Skills carry the know-how, MCP carries tool connections, and `plugin.json` tells different clients how to recognize the package.
The problem it addresses is distribution. A capability that works in one client has traditionally needed a new directory layout, manifest, and MCP configuration when moved to another. The standard fixes that outer wrapper, with the goal of packaging once and loading the shared parts in several compatible clients.
Why It Became a Hot Term in August 2026
Agent Plugins 1.0.0 was published on August 6, 2026. Its initial Technical Steering Committee included core maintainers from AWS, Cursor, Microsoft, OpenAI, and Vercel; Google subsequently joined as a core maintainer. That multi-vendor participation distinguishes it from a private plugin format owned by one product.
The timing is straightforward. Skills had made procedural knowledge reusable, while MCP had made external tools portable across clients. What remained missing was a common box for shipping the two together. Agent Plugins fills that packaging layer.
What Is Inside a Plugin
The minimum plugin is a directory with a required plugin.json at its root. The manifest declares metadata such as identity, version, and description, and points the client toward discoverable components. Skills normally live under skills/; MCP server connection details can live in mcp.json. Client-specific data belongs under namespaced extensions rather than pretending to be portable configuration.
One boundary matters: a plugin is not a long-running agent and not a new communication protocol. It is an installable, validatable, discoverable capability package. The host client, model, Skill instructions, and MCP servers still do the actual work.
How It Differs from Skills, MCP, and Traditional Plugins
Agent Skills answers “how should this task be done?” MCP answers “which tools and data can be reached?” Agent Plugins answers “how do we ship those pieces together?” They stack; they do not replace one another.
Traditional IDE or browser plugins usually depend directly on one host API and must be rewritten for another host. Agent Plugins aims to keep the common portion portable while allowing clients to add features under extensions. “Package once, run everywhere” remains conditional: the destination must support the plugin version, component types, and MCP transports the package uses.
When It Is Worth Using
A plugin makes sense when a capability combines stable procedures with external connections and needs to be distributed across a team or several clients. Examples include querying an internal warehouse and drafting a weekly report, enforcing a team’s code-review process, or reading a ticket and creating a repair branch.
For one short instruction, a Skill is enough. For a standalone tool surface, publishing an MCP server is simpler. A capability tied to one private host may not benefit from the additional portability layer.
Security and Limitations
Installable does not mean trustworthy. A plugin may declare local commands, remote MCP endpoints, and environment variables. Users still need to verify provenance, permissions, and changes. Compatible clients should validate manifests against the schema before discovery or execution.
As of August 2026, version 1.0.0 is published, but clients do not all support the same component types, transports, or extension fields. The compatibility matrix—not a generic “supports Agent Plugins” badge—is the reliable way to judge whether a particular package will work.