Agent Plugins Standardize Packaging for Skills and MCP Servers

Corey Ching presents Agent Plugins as an answer to a specific interoperability problem: skills and MCP servers are making agents more capable, but agent products currently expect different manifests, folder structures, and setup processes. The proposal is to give plugin authors a vendor-neutral format for packaging an extension, and agent tools a predictable way to find it.

That boundary is the central design choice. The specification addresses how reusable capabilities are organized and discovered across products; it does not establish a shared marketplace, permissions model, or runtime. The displayed manifest also allows client-specific interface metadata, rather than requiring every supported product to present a plugin in the same way.

The announcement identifies AWS, Cursor, GitHub, Microsoft, OpenAI, and Vercel as contributors. Their shared specification is intended to reduce the platform-specific packaging work involved in making a capability available to different agent environments.

A practical plugin begins with a required plugin.json file at the root of its directory. Optional resources then live in standard locations: skills under skills/, and MCP server configuration in mcp.json. The package layout shown also includes locations for scripts, references, hooks, and client-specific material. Not every plugin needs every component; the format provides recognized places for those components when they are included.

The first release focuses on two kinds of resources developers already use. As Corey Ching describes them, agent skills package reusable instructions and workflows; MCP servers connect agents to tools and data. An agent product can support skills, MCPs, or both.

The documentation shown in the announcement describes an Agent Plugin as a portable directory containing the root manifest and optional components in fixed locations. Its example directory includes skills/summarize/SKILL.md and an mcp.json file. A separate hello-plugin example makes the minimum structure especially plain: plugin.json is marked required, while the skills/ folder is optional.

That small manifest identifies both the applicable Agent Plugins schema and the package name:

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

The specification’s practical promise is not that every client will use every resource in a package. It is that a client looking for skills or MCP configuration can find those resources according to a common layout rather than a product-specific folder convention. For authors, Ching frames the payoff as less platform-specific glue and one versioned format to build against.

Portability does not mean a plugin has identical configuration everywhere. The expanded hello-plugin manifest shown in the announcement contains shared fields for schema, name, version, and description, plus an extensions object for client-specific data.

Corey Ching points to the structure as a way for agent products to extend the format without changing its portable core. In the displayed example, the com.openai extension includes interface information: a short description and a logo. The com.cursor extension supplies an icon. The visual summarizes the arrangement as “client extensions without duplicating the core.”

The result is a package that can keep its shared identity, skills, and MCP configuration together while carrying extra metadata for particular clients. The source’s stated division of responsibility is narrow but deliberate: authors package a capability in the common format, and agent products add support for the resources they choose to recognize.

The specification is described as open and ready to build with. Developers can find the project and its getting-started material at agent-plugins.org.