From Skills and Tools to Portable Agent Plugins

AI agents have become remarkably extensible. Agent Skills can give them reusable instructions, scripts, and reference material. Model Context Protocol (MCP) servers can connect them to databases, browsers, source control, cloud platforms, and other live systems.

But sharing those capabilities still has a packaging problem.

Imagine building a deployment assistant. Its Skill explains how your organization prepares a release, checks service health, and rolls back safely. Its MCP server connects the agent to your deployment platform. The underlying components can work across agent clients, but distributing them often means rearranging files, rewriting manifests, or maintaining a separate package for each client.

Agent Plugins 1.0 addresses that gap with an open, vendor-neutral specification that gives those portable components one predictable package format.

Agent Plugins does not replace Agent Skills or MCP. It packages them without changing their native formats. It also does not attempt to make every agent client behave the same way. Version 1.0 defines a small interoperability floor: enough structure for compatible clients to discover and load the portable parts, while leaving installation, permissions, user experience, and client-specific innovation under each client's control.

A shared package boundary

An Agent Plugin is a directory with a small manifest and fixed locations for its components:

deployment-assistant/
├── plugin.json
├── skills/
│   └── deploy-service/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
├── mcp.json
└── com.example.client/
    └── hooks/

The minimal manifest identifies the specification version and names the plugin:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "deployment-assistant"
}

The file structure is the contract. Compatible clients check the manifest, discover Skills under skills/, and read MCP server configuration from mcp.json. The namespaced directory belongs to an individual client, which can use it for capabilities outside the portable 1.0 contract. Other clients ignore namespaces they do not implement.

This keeps the shared format predictable without requiring it to absorb every client-specific experiment happening across agent products.

How the pieces fit together

Agent interoperability is not one problem, and no single specification should try to solve all of it.

For our deployment assistant:

• Agent Skills packages procedural knowledge and supporting resources. The Skill can explain when to deploy, which checks to run, and how to respond when something fails.
• MCP standardizes how the agent connects to live tools and contextual data at runtime. The MCP server can expose deployment status, health checks, and rollback operations.
• Agent Plugins packages those reusable components together so compatible clients can discover them in a consistent structure.
• The client decides how the plugin is installed, which components it supports, what permissions are required, and how capabilities appear to the user.

Here is the payoff. An SRE packages the deployment assistant once, combining the deploy-service Skill with MCP configuration for the deployment platform. A teammate can open that package in another compatible client and load the same portable components without rearranging the files or rewriting the manifest. Each client can still add its own experience around them.

An Agent Plugin can contain Skills, MCP server configuration, or both. Meanwhile, the MCP community's Skills over MCP effort is exploring how Skills can be discovered, distributed, and consumed through MCP. That work is complementary: Skills over MCP focuses on distributing Skills through MCP, while Agent Plugins defines self-contained packages that can compose Skills, MCP server configuration, and client-specific additions.

Deliberately narrow in 1.0

What 1.0 includes

Agent Plugins 1.0 standardizes two component types: Agent Skills and MCP servers.

Both already have open specifications and meaningful adoption across agent clients. Standardizing how a plugin carries them creates immediate portability without redefining their behavior. Version 1.0 also defines:

• a required package manifest and fixed component locations;
• validation and failure-isolation rules;
• portable path variables; and
• namespaces for client-specific extensions.

What may come next

Client ecosystems also experiment with agents, commands, hooks, rules, and user-interface extensions. These concepts do not yet have consistent semantics or security models across clients, so they are not portable component types in 1.0.

They may become candidates for future versions as implementations converge and demonstrate a concrete portability need. In the meantime, reverse-domain extension namespaces let clients keep experimenting without changing the shared contract. No additional component type is committed for a future release.

What remains client-owned

Agent Plugins intentionally leaves several product and ecosystem decisions outside the portable format:

• Distribution: registries, marketplaces, installation, and updates.
• Runtime experience: permissions, approval flows, sandboxing, and user interface.
• Trust: publisher identity, provenance, signatures, and organizational policy.

Packaging, discovery, and trust

MCP, an AAIF project, standardizes how AI applications connect to tools and contextual data at runtime. Agent Plugins is a complementary, independently governed effort: it defines how MCP server configuration and Agent Skills can travel together as a package.

Agent Plugins defines how a client discovers components inside a package, but not how users or clients find plugin packages across an ecosystem. That broader discovery problem is a separate concern, which AAIF has described as a missing layer in AI interoperability. Emerging efforts such as AI Catalog explore how clients and registries might find and describe different AI artifacts across ecosystems.

Agent Plugins does not require a particular registry or catalog. A catalog can point to plugins, just as it can point to agents, MCP servers, or other artifacts. Finding a package is also not the same as trusting or executing it: publisher verification, provenance, approval, sandboxing, and runtime policy remain separate responsibilities.

The concerns compose, but no single organization or specification owns the entire stack:

Built across the ecosystem

Agent Plugins 1.0 was developed collaboratively by representatives from Amazon, Cursor, Microsoft, OpenAI, and Vercel. The project is openly licensed, its specification and schemas are developed in public, and its Technical Steering Committee includes Core Maintainers from each participating organization.

"Useful capabilities should be able to travel across agents. By building a shared, open standard that’s simple to adopt, Agent Plugins unlocks interoperability across the agent ecosystem. That not only gives developers room to keep innovating, but helps more people benefit from what they build.” -Nick Cooper, OpenAI

The project follows a simple principle for growing the portable contract: new features should start with a concrete cross-client need and evidence that implementers are prepared to support the same semantics. Proposals begin in public GitHub Discussions, where plugin authors, client implementers, and the broader community can help shape future versions.

The compatible clients page currently lists VS Code, Cursor, GitHub Copilot, OpenAI Codex, and Kiro. It tracks which portable components and MCP transports each client supports, backed by public product evidence.

Build once, carry the portable parts forward

Plugin authors can keep Skills in their native format, keep MCP behavior grounded in the MCP specification, and distribute both through one portable manifest. Client implementers gain a predictable package boundary while retaining control over their product experience, supported components, and transports.

The format gives the ecosystem a place to converge without asking clients to stop innovating.

To get started:

• Read the Agent Plugins 1.0 specification
• Build an Agent Plugin
• Implement Agent Plugins in a client
• Browse compatible clients
• Join the project discussions

Agent Skills made reusable procedural knowledge portable. MCP made tools and context available through a shared runtime protocol. Agent Plugins now gives those building blocks a shared package boundary.

We are excited to see what you build with it—and where the ecosystem takes the format next.