Agent Plugins: The Next Standard for Simplifying AI Agent Development
MCP (Model Context Protocol) has been emerging as one of the leading standards for connecting AI agents to tools, APIs, and services (learn more here and here).
Now, a new initiative is gaining attention: Agent Plugins 1.0, an open specification for packaging Agent Skills and MCP servers into a single portable plugin.
At first glance, it may seem like a minor implementation detail.
But it addresses a real challenge for developers building AI agents: how to package and distribute these capabilities in a reusable way across different clients and platforms.
The project is maintained by representatives from Amazon, Microsoft, OpenAI, Cursor, Vercel, and now Google, which recently joined the group of Core Maintainers.
Follow our page on LinkedIn for more content like this! ❤
See also
When AI Agents Reach Real-World Systems: What the OpenAI and Anthropic Incidents Teach Us
Want to build Machine Learning models for trading and financial markets?
What Every AI Engineer Should Know About Context Engineering
The Problem Agent Plugins Is Designed to Solve
The Problem Agent Plugins Solves
Imagine you’ve developed a powerful set of capabilities for an AI agent:
a Skill specialized in data analysis;
an MCP server for accessing a database;
a few supporting resources.
So far, so good.
The challenge begins when you want to distribute that work across different clients, such as Cursor, Claude Code, Gemini CLI, or other platforms.
The Skill remains the same.
The MCP server remains the same.
What changes is how each client expects those components to be organized and configured.
Each platform may require a different manifest, directory structure, or configuration conventions. As a result, developers often end up maintaining multiple versions of the same package, even though the underlying logic remains identical.
It’s a packaging problem, not a functionality problem.
What Exactly Is an Agent Plugin?
Agent Plugins addresses precisely this layer.
The concept is surprisingly simple.
An Agent Plugin is essentially a directory organized according to a standardized structure.
Instead of every platform defining its own format, the specification establishes a common layout for organizing Skills, MCP servers, and metadata.
Its main components include:
plugin.json: a minimal manifest that identifies the plugin;
skills/: contains one or more Agent Skills, each in its own directory;
mcp.json: declares the MCP servers used by the plugin;
optional client-specific directories for proprietary extensions.
The goal is to minimize the decisions each client needs to make in order to locate these components.
Rather than inventing its own conventions, every compatible client looks for the same files in the same locations.
The goal is for a single plugin to work across multiple compatible clients without requiring different packaging formats.
An Interesting Design Choice: Independent Components
One aspect I found particularly interesting is how the specification handles failures.
If an MCP server fails to start, the plugin’s Skills can still be loaded.
Likewise, if a plugin doesn’t contain any Skills, its available MCP servers can still be used.
Each component is treated independently.
As a result, a failure in one component doesn’t prevent the others from being loaded.
When Does It Make Sense to Use an Agent Plugin?
When Does It Make Sense to Use an Agent Plugin?
Not every Skill needs to become a plugin.
If you have a single standalone Skill or an MCP server intended for a specific client, using those components on their own may be enough.
Agent Plugins become valuable when multiple components belong to the same project and need to be packaged and distributed together.
In other words, they solve an organization and distribution problem, not an execution problem.
What Agent Plugins Doesn’t Solve
Another interesting aspect is what the specification deliberately leaves out.
It does not define:
installation mechanisms;
plugin distribution;
permission management;
authentication;
execution sandboxing;
security policies;
trust or provenance verification.
These concerns remain the responsibility of each client platform.
According to the authors, this decision was intentional. An IDE, a command-line tool, and an enterprise platform all have very different requirements when it comes to installation, security, and user experience.
How It Fits into the Broader Ecosystem
The announcement also shows that Agent Plugins are part of a broader ecosystem.
Each standard has a well-defined responsibility:
Agent Skills define an agent’s specialized behavior and knowledge.
MCP (Model Context Protocol) connects agents to tools and services.
Agent Plugins package these components into a portable format.
AI Catalog describes these resources for publication.
Agentic Resource Discovery (ARD) enables clients to discover compatible resources before using them.
According to the authors, each layer has a specific responsibility and can be adopted independently of the others.
You can use Agent Skills without Agent Plugins.
You can use MCP without AI Catalog.
And you can publish an Agent Plugin without relying on a specific discovery mechanism.
🚀 Want to Stay Up to Date on AI?
This newsletter is for you!
Every week, I share insights on AI concepts, research papers, tools, and real-world developments for professionals, researchers, and anyone interested in understanding where AI is heading.
Subscribe and join me for the next edition.
Conclusion
Over the past few months, MCP has gained significant momentum.
Now, another layer is beginning to emerge: a standard for packaging and distributing these capabilities.
If MCP is becoming the standard interface between AI agents and tools, Agent Plugins could become the standard format for packaging and sharing those capabilities across different platforms.
It’s still too early to predict how widely it will be adopted.
However, the ecosystem appears to be moving toward greater interoperability, less fragmentation, and a better developer experience for those building AI agents.
If that happens, it could significantly accelerate the evolution of the agent ecosystem.
As the authors summarize, the problem isn’t the Skills or the MCP servers—it’s how they’re packaged.
What do you think?
Do you believe we’ll see an ecosystem of interoperable plugins across different AI agent platforms, or will each vendor continue investing primarily in its own formats?
That's a reputation and permissions problem wearing an interoperability costume. "Trust" here isn't really about whether the plugin's code is good, it's about whether the agent (or the person who owns the agent) can afford to be wrong about it. Which makes me think the winning model borrows more from package managers with sandboxing and signed provenance than from app stores with manual review — review doesn't scale to the volume, but a blast radius does.
The independent-failure design is the detail I'd bet on more than the packaging spec itself. Most "standard" proposals die because they assume a clean adoption path, but real systems fail partially, not wholesale — an MCP server going down without taking your skills with it is the kind of boring reliability decision that actually survives contact with production. My guess on your closing question: we get real interoperability at the plugin layer (too useful to skip) but vendors still fight over the discovery/trust layer, since that's where the actual lock-in value sits.