Agent Plugins: The New Standard for Packaging AI Agent Skills and MCP Servers

On August 6, 2026, six companies that compete on almost everything else agreed on how to package an AI agent extension. Vercel published the Agent Plugins standard with contributions from Amazon Web Services, Anysphere (the company behind Cursor), GitHub, Microsoft, and OpenAI, and Google joined the project's Technical Steering Committee the same day. The agent plugins standard defines a single folder format for two things people building agent systems already use separately: Agent Skills, which are saved instructions an agent follows, and MCP servers, which connect an agent to a live tool or data source. Build one plugin, and it now runs in ChatGPT, Codex, Cursor, GitHub Copilot, Kiro, and VS Code without separate integration work for each.

The problem it actually solves

Before this, a developer who wanted their extension available in more than one agent client had to adapt it repeatedly. A skill written for one tool needed its own packaging to work in another. An MCP server configuration that worked in Cursor needed to be rewritten to work in VS Code. None of the format was hard to build, but every client wanted it shaped slightly differently, so authors either picked one client and left the rest of the market uncovered, or maintained several near-duplicate versions of the same thing.

Agent Plugins removes that by defining the shape of the package rather than the behavior inside it. According to Vercel's announcement, the goal is that authors "package components once, and their plugin will automatically carry between supporting clients." That is a narrower promise than it sounds. The standard does not touch how a plugin is discovered, installed, sandboxed, or trusted. Vercel, as the initiating author, left marketplaces and permissions to each client to decide on its own.

What a plugin actually contains

A minimal Agent Plugin is a folder with a required plugin.json manifest at its root. The bar to publish one is low. The manifest needs only two fields to be valid:

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

From there, a skills/ directory holds Agent Skills components, and an mcp.json file declares MCP server configuration, including transport type. A plugin that needs to do something specific to one client without breaking on the others can add a reverse-domain namespace folder, like com.example.client/, that only that client reads. Everything else in the folder is meant to be read the same way by every compatible agent.

That structure matters more than it looks. It means a plugin author writes the skill and the MCP server configuration exactly once, and the packaging layer that used to eat the remaining effort, per-client adaptation, mostly disappears. Google's own developer blog frames the same idea from the consuming side: "Plugin authors shouldn't have to choose between reaching every client and using what makes each client good."

Why the standard stays deliberately small

The Technical Steering Committee that governs Agent Plugins now includes core maintainers from AWS, Cursor, Microsoft, OpenAI, Vercel, and Google, represented by Kevin Hou of Google DeepMind. Its governance, contribution process, and technical decisions are public on GitHub, and no single company's product roadmap sets the direction.

The restraint is the actual design decision worth noticing. A standard that tried to also settle how plugins get discovered, who is allowed to publish one, and how a client decides to trust one would have taken far longer to agree on, if six competing companies could agree on it at all. By defining only the shape of the package, Agent Plugins asks each company to give up almost nothing, which is exactly why AWS, Cursor, GitHub, Microsoft, OpenAI, Vercel, and now Google could sign off on it inside the same week. It is the same trade every earlier interoperability standard has made: agree on the smallest possible surface, and let everything downstream of that stay a place companies still compete.

This sits next to a related shift this site covered on July 29, when MCP dropped the concept of a session and moved to plain, stateless requests. Both changes point the same direction: the protocol pieces an agent depends on, how it talks to a tool and how that tool gets packaged for distribution, are being simplified and standardized at the same time the agents built on top of them are getting more capable.

What this means if you are building agent systems

If you already maintain a Claude Code skill, a Codex extension, or an MCP server that connects an agent to a real service, Agent Plugins packaging is the difference between writing it once and writing a version per client. Practically, that means:

• A skill or MCP server you built for one agent client can now reach six at launch without you writing separate integration code for each, as long as you package it to the 1.0.0 schema.
• The manifest requirement is intentionally low, two fields, so converting an existing skill or MCP configuration into a plugin is closer to a packaging exercise than a rewrite.
• Google's products, including Agents CLI and Data Agent Kit, are adopting the format immediately, with plans to extend it to more products that already support Skills and MCP servers, which signals this is not a one-vendor bet that might not last.
• Nothing about discovery or trust changed. A plugin still has to be found and installed through whatever mechanism each client uses, so packaging correctly does not by itself get you distribution, it removes the technical excuse not to be everywhere your users already are.

For anyone building tooling that an agent is meant to use, whether that is a Skill that encodes how your product should be operated or an MCP server that gives an agent live access to your data, the practical move is to check whether your packaging already matches the plugin.json and skills/ structure above. If it does not, the standard is new enough, and the manifest simple enough, that bringing it into line is a small job now and a much bigger one once six separate client-specific formats have each grown their own workarounds.

Sources: Vercel, "Introducing Agent Plugins", Google Developers Blog, "Agent Plugins package your skills, tools, and more", The Next Web