Agent Plugins: A Vendor-Neutral Package Format for Skills and MCP Servers

Key Takeaways

• A plugin is just a folder. At its simplest, an agent plugin is a directory containing a manifest called plugin.json at the root — no build step, no registry, no proprietary bundle format.
• The first release covers two things developers already use: agent skills (reusable instructions and workflows) and MCP servers (connections to tools and data). Put those resources in the standard locations and the same package becomes much easier to support across products.
• It is cross-vendor from day one. AWS, Cursor, GitHub, Microsoft, OpenAI and Vercel contributed. That breadth matters more than the spec's technical content — a packaging standard is only worth adopting if the products you target already read it.
• Agent products can support skills, MCP servers, or both, and can extend the format without breaking its portable core. A tool that only understands skills should still be able to consume a package that also ships an MCP server.
• The scope is deliberately narrow. The spec standardises packaging and discovery only. It explicitly does not cover marketplaces, permissions or runtimes — so it is not a security model, and installing a plugin still means running someone else's instructions and servers on your machine.
• The payoff for authors is less platform-specific glue — one version of the format to build against, instead of maintaining a separate packaging path per agent product.

Why this matters for the ecosystem

Skills and MCP servers are the two mechanisms that have actually stuck as ways of extending agents, and until now the distribution story for both has been per-platform. Anyone maintaining a skill for more than one agent has been maintaining a set of near-identical folder layouts that differ only in where the host looks. A shared package shape removes that duplication and makes it realistic for a single skill to be published once and consumed by several agents.

The caveat worth holding onto is what the spec says it is not. Standardising discovery without standardising permissions means the install-time trust question is unchanged — a plugin that is easier to distribute is also easier to distribute carelessly. Our security centre covers what to check before installing third-party skills, and the same review applies here: read the skill instructions, check what MCP servers the package wires up, and confirm what those servers can reach.

Related reading: writing your own skills, MCP tools in Hermes, and the glossary entry on MCP.