Agent Plugins

Agent Plugins answers a narrow question that got expensive fast: if I have written a skill and wired up an MCP server, how do I hand that to somebody using a different agent client without repackaging it? Every coding agent grew its own plugin layout, its own mcp.json shape, and its own place to put instructions, so the same handful of components got rewritten per vendor. The specification’s response is deliberately unambitious: define the package boundary, define two component types that already have specifications of their own, and put everything else out of scope. Version 1.0.0 is published, licensed CC BY 4.0 for the specification text and Apache 2.0 for the schemas, and developed in the open at agentplugins/agent-plugins-spec with a Technical Steering Committee of five Core Maintainers — Clare Liguori (Amazon), Roshan Sadanani (Cursor), Harald Kirschner (Microsoft), Gav Verma (OpenAI) and Jonathan Hefner (Vercel, Lead Core Maintainer).

• A plugin is a directory, not an archive - No .zip, no .tar.gz, no registry-fetched bundle. The stated reason is that a directory stays inspectable with ls and cat, editable in place, and versionable in Git without special tooling. Fixed root-level locations remove the discovery indirection every client would otherwise implement.
• A closed manifest - plugin.json permits exactly eleven top-level fields: $schema, name, version, description, author, homepage, repository, license, keywords and extensions. Only $schema and name are required. Closing the manifest is what makes strict validation and typo detection possible; client experiments are confined to extensions.
• Two component types, both borrowed - skills/ holds Agent Skills, whose SKILL.md format is governed by the separate Agent Skills specification, and mcp.json declares MCP servers. The stated bar for inclusion was an established specification outside this project plus real cross-client adoption — which is why commands, hooks, agents, rules and LSP servers were all left out of v1.
• Reverse-domain extensions instead of a name registry - Client-specific data nests under extensions["com.example.client"], and a client-specific directory takes the same name at the plugin root. A client MUST ignore namespaces it does not implement without validating them, so one package can carry five vendors’ quirks and still load cleanly in all five.
• An explicit MCP transport union - stdio, streamable-http and sse, each entry declaring its own. A conformant client MUST support at least one of stdio or streamable-http and SHOULD support both; HTTPS is required for anything not on loopback. Distinguishing Streamable HTTP from legacy HTTP+SSE is a direct shot at clients that today infer the transport from the URL.
• Two variables, and only two - ${PLUGIN_ROOT} and ${PLUGIN_DATA} expand in args, env values and cwd — single textual replacement, non-recursive, and unrecognized placeholder-like text MUST stay literal. There is no general environment-variable interpolation, command is one token with no shell parsing, and the resolved path MUST remain inside the plugin root.
• Failures are non-fatal and must be visible - An MCP server that will not start does not take the plugin’s skills down with it, and a non-conformant skill is skipped rather than fatal. The specification pairs that with a diagnostic requirement so the failure surfaces instead of disappearing.
• Schemas share the specification version - Both schemas live at https://agent-plugins.org/schemas/1.0.0/, $schema is a required and exact-matching field, and clients MUST NOT fetch a schema while loading a plugin. One version number covers the format, and canonical identifiers are never reassigned. Plugin version itself SHOULD follow Semantic Versioning, and license SHOULD be an SPDX identifier.
• Individuals hold the seats, not companies - The Technical Charter is explicit that no seats are reserved for specific organizations and no single vendor may control a majority of Core Maintainer seats. Proposals start in GitHub Discussions, and a technically complete pull request is explicitly not treated as evidence of implementor consensus.

Five clients are listed as compatible at launch — VS Code, Cursor, GitHub Copilot, ChatGPT & Codex and Kiro — all five supporting skills, all five supporting stdio and streamable-http. That is an unusual starting position for a specification: the adoption is stated before the ink dries rather than hoped for afterward, and the format itself will look familiar to anyone who has already written a plugin for a coding agent, because it is largely the layout that ecosystem converged on being written down. It is also worth naming what is not there. Anthropic sits on neither the steering committee nor the compatible client list, despite Agent Skills being the component type the format leans hardest on. And v1.0.0 has no trust model, no signature or provenance verification, no secrets handling, no dependency resolution and no registry — the FUTURE_CONSIDERATIONS.md file lists all of them as open. So this standardizes how a plugin is shaped, not how you decide whether to trust one, which is the harder half. For API providers the practical read is the same as with MCP and ARD: the packaging question is settling, the discovery and trust questions are not, and a plugin directory is now a cheap way to ship your API’s tooling to five clients at once instead of one.