Agent Plugins 1.0: Portable Package Format for AI Skills

thm1 pts0 comments

Agent Plugins 1.0: Portable Package Format for AI Skills - Agentic AI Foundation (AAIF)

AGNTCon+MCPCon Europe • Sep 17-18 • Amsterdam • REGISTER NOW

Icon Close

span]:bg-coral-500 [&>span]:h-0.75 [&>span]:absolute [&>span]:rounded-full [&>span]:transition-transform [&>span]:duration-300">

Join AAIF

From Skills and Tools to Portable Agent Plugins

Harald Kirschner<br>August 6, 2026

This is a community guest post from the Agent Plugins Technical Steering Committee. Agent Plugins is an independently governed open specification. It is not an AAIF project and has not submitted a proposal to become one.<br>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.<br>But sharing those capabilities still has a packaging problem.<br>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.<br>Agent Plugins 1.0 addresses that gap with an open, vendor-neutral specification that gives those portable components one predictable package format.<br>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.<br>A shared package boundary<br>An Agent Plugin is a directory with a small manifest and fixed locations for its components:

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

The minimal manifest identifies the specification version and names the plugin:<br>json<br>"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",<br>"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.<br>This keeps the shared format predictable without requiring it to absorb every client-specific experiment happening across agent products.<br>How the pieces fit together<br>Agent interoperability is not one problem, and no single specification should try to solve all of it.<br>For our deployment assistant:<br>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.<br>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.<br>Agent Plugins packages those reusable components together so compatible clients can discover them in a consistent structure.<br>The client decides how the plugin is installed, which components it supports, what permissions are required, and how capabilities appear to the user.<br>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.<br>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.<br>Deliberately narrow in 1.0<br>What 1.0 includes<br>Agent Plugins 1.0 standardizes two component types: Agent Skills and MCP servers.<br>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:<br>a required package manifest and fixed component locations;<br>validation and failure-isolation rules;<br>portable path variables; and<br>namespaces for client-specific extensions.<br>What may come next<br>Client ecosystems also experiment...

agent skills client plugins portable deployment

Related Articles