Agent Plugins 1.0 unifies agent skills across five clients

If you have built an MCP server or an agent skill in the past year, you have probably packaged it for one client. Maybe two, if you had the stamina. The manifest formats, discovery rules, and component layouts differ enough across VS Code, Cursor, and Copilot that shipping the same capability everywhere meant maintaining near-duplicate packages with incompatible manifests. That fragmentation is what Agent Plugins 1.0 set out to kill.

On August 6, 2026, a group of core maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel published Agent Plugins 1.0.0, an open, vendor-neutral specification for packaging Agent Skills and MCP servers into portable plugins. Five clients already document support: VS Code, Cursor, GitHub Copilot, ChatGPT and Codex, and Kiro. Google announced it is joining the core maintainer group as well, represented by Kevin Hou, and starting to build support into its own products. The format is small by design: a directory with a plugin.json manifest, a skills/ folder, and an mcp.json file. It defines no install mechanism, no permission model, no sandboxing, and no trust verification.

What actually shipped with Agent Plugins 1.0?

The specification is a package format and nothing more. The authors name that scope openly in the project's future considerations rather than quietly omitting the gaps. A plugin is a directory. At the root sits a minimal plugin.json manifest that identifies the specification version and names the plugin. The manifest is two lines of substance: a schema reference and a name field.

From there, everything lives at a fixed location. Skills go in skills/, one subdirectory each, in the format the Agent Skills specification already defines. MCP servers are declared in mcp.json, with an explicit transport type on every entry. A client never guesses a transport from the shape of a config object. The spec supports three: standard input and output, Streamable HTTP, and legacy HTTP+SSE.

The last piece is the escape hatch. A directory named with a reverse-domain pattern like com.example.client/ is an extension namespace owned entirely by one client. Hooks, agents, commands, or anything else a specific client wants to add go there. Clients that do not recognize it ignore it. The portable core stays small because the non-portable parts have somewhere legitimate to go.

Components fail independently. If mcp.json declares a server that fails to start, the client skips that entry, keeps loading the plugin's skills, and reports the failure. One broken MCP server does not take down the skills that ship alongside it. The spec's authors made isolation a property of the format, not a feature a client has to bolt on afterward.

Which clients support it and what does that cover?

The Agent Plugins site lists five compatible clients at launch. Every one of them documents support for Agent Skills. Every one of them supports MCP over stdio and MCP over Streamable HTTP. Support for legacy HTTP+SSE varies across the listed clients, so check your target client before relying on it.

The chart above shows the matrix: all five clients, three capabilities, universal support across every cell. Microsoft updated its VS Code agent-plugin documentation on August 6 to describe the open standard alongside its existing format. VS Code had supported its own agent-plugin packages since earlier in 2026, but the revised documentation says the editor now detects a standard package when its root manifest declares the canonical Agent Plugins 1.0 schema. VS Code continues to recognize existing Copilot, Claude, and legacy OpenPlugin package formats separately, so nothing breaks for developers who have already shipped plugins in those formats.

The client list matters because it spans the tools developers actually use. VS Code is the dominant editor. Cursor is the AI-first challenger. GitHub Copilot runs inside VS Code and GitHub.com. ChatGPT and Codex cover OpenAI's surface. Kiro, Amazon's agentic IDE, rounds out the set. If you package a skill or MCP server as an Agent Plugin, it works in every one of them without repackaging.

Why does a shared format change how you package agent tools?

The practical consequence is straightforward. Today, if you build an MCP server that exposes your company's internal tools to an AI agent, you package it differently for each client. VS Code wants one manifest shape. Cursor reads another. Copilot has its own discovery rules. Each client's format is documented, but none of them talk to each other. You end up with a matrix of packages that all do the same thing.

Agent Plugins 1.0 collapses that matrix. One plugin directory, one plugin.json, one skills/ folder, one mcp.json. Write it once, ship it everywhere. For a team that maintains agent tools across multiple IDEs, that is fewer manifests to keep in sync and fewer format-specific bugs to chase.

Here is what this means for you:

• One package, five clients. A skill you write in the Agent Skills format and ship under skills/ works in VS Code, Cursor, Copilot, ChatGPT and Codex, and Kiro without modification.
• Independent failure isolation. If one MCP server in your plugin fails to initialize, the rest of the plugin keeps working. You debug one component, not the whole package.
• Client-specific extensions stay local. The com.example.client/ namespace lets you add VS Code-specific hooks or Cursor-specific commands without polluting the portable core.
• Backward compatibility. VS Code still detects Copilot, Claude, and legacy OpenPlugin formats. Your existing packages do not break. You can migrate when you are ready.

For a solo founder building agent tools, this means you can ship a single plugin package and reach the installed base of five clients. For a platform team, it means one build pipeline instead of five. The savings show up in maintenance hours, not in inference bills, but they are real.

What did the spec deliberately leave out?

The spec defines no install mechanism, no distribution protocol, no permission model, no sandboxing requirements, no trust or provenance verification, and no user experience. The Vercel announcement names these gaps openly in the project's future considerations. The Google Developers Blog confirms the scope bluntly: "Agent Plugins v1 is a package format and nothing more."

This is the part that should make you pause. An MCP server packaged as an Agent Plugin can expose filesystem access, network calls, and code execution to an AI agent. The format says nothing about how a client should prompt the user for consent, how to sandbox the server's capabilities, or how to verify that the plugin came from a trusted source. Each client implements those controls on its own, or does not.

The security gap is real, not hypothetical. As we have covered, agentic MCP attacks bypass state-of-the-art guardrails 58 percent of the time, and 54 percent of enterprises have already been hit by agent credential-sharing exploits. A portable plugin format that standardizes how tools are packaged but not how they are permissioned makes the attack surface wider, not narrower. More clients reading the same mcp.json means more entry points for a malicious or compromised server.

The spec's authors would argue that permission models and sandboxing are client responsibilities, and that a package format should leave them to the client. That is a defensible architectural choice. It is also the same choice that produced the browser extension security mess: a shared format, no shared trust model, and a long tail of malicious packages that followed.

How do you build a plugin that works across all five clients?

Start with the directory structure:

my-plugin/
  plugin.json
  mcp.json
  skills/
    my-skill/
      skill.md
  com.example.client/
    hooks.json

The plugin.json manifest is minimal:

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

The mcp.json file declares each MCP server with an explicit transport type:

{
  "mcpServers": {
    "my-server": {
      "type": "stdio",
      "command": "node",
      "args": ["server.js"]
    }
  }
}

That is the entire contract. Drop the directory into a location your client scans for plugins, and the client discovers the skills and MCP servers from their fixed paths. No relocation, no inline declaration, no precedence order to learn. If skills/ is not there, the client loads what is present and moves on.

The spec supports three MCP transport types. Use stdio for local servers that run as subprocesses. Use Streamable HTTP for remote servers that expose a single endpoint. Use legacy HTTP+SSE only if you are maintaining an older server that has not migrated, and check whether your target client supports it, because not all five do.

The real test is whether trust catches up to portability

Agent Plugins 1.0 solves a real problem. Packaging agent skills and MCP servers for five clients with one format is a genuine reduction in friction, and the backing of Amazon, Microsoft, OpenAI, Cursor, Vercel, and now Google gives it the momentum to stick. The format is clean, the isolation model is sound, and backward compatibility is handled.

But a portable package format without a portable trust model is a loaded weapon. Every client that adopts Agent Plugins inherits the job of sandboxing untrusted MCP servers and prompting for permissions that the spec does not define. Some will do it well. Some will not. The question is whether the Open Secure AI Alliance's agent security tools or an equivalent effort produces a shared permission layer before the plugin ecosystem grows large enough that a malicious Agent Plugin becomes a routine incident. The format is ready. The trust model is not.

Sources

• Vercel Blog: Introducing Agent Plugins
• Google Developers Blog: Agent Plugins package your skills, tools, and more
• Visual Studio Magazine: VS Code Agent Plugins Go Cross-Client with New Open Standard
• Virtualization Review: Cloud Giants Back Agent Plugins for Cross-Client AI
• The Next Web: OpenAI and four rivals just agreed on one standard for AI agents