Agent Plugins Explained: The New Skills + MCP Standard

A new word just landed in the SKILL.md ecosystem

On 6 August 2026, five companies that don't usually publish specs together (Amazon, Cursor's maker Anysphere, Microsoft, OpenAI and Vercel) jointly released Agent Plugins 1.0.0, an open standard for packaging Agent Skills and MCP servers into one distributable folder. The spec itself lives at github.com/agentplugins/agent-plugins-spec, and the first shipping implementation, in OpenAI's Codex CLI, landed a day later.

If you already run skills in Claude Code, Codex CLI or Cursor, the useful question isn't "should I switch to this", because nothing about your existing setup breaks or needs migrating. It's "what does this actually add, and does it change anything about how I ship a skill." This piece works through both.

What a plugin actually is

Strip away the announcement and a plugin is a directory with a manifest file next to it. The spec's own minimal example is close to the whole idea:

hello-plugin/
├── plugin.json
└── skills/
    └── greet/
        └── SKILL.md

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

plugin.json is the only strictly required file. $schema and name are the only required fields. Everything else in the manifest is optional metadata: version, description, author, homepage, repository, license, keywords. A plugin can bundle a skills/ directory, an mcp.json file describing MCP servers, or both.

The important detail, and the one that should reassure anyone who's already invested in the current format: skills inside skills/ use the identical SKILL.md structure that a standalone skill already uses. The spec's own text is explicit that a plugin just recognises "each immediate child directory containing a file named exactly SKILL.md" as one skill: same YAML frontmatter, same name and description fields, same optional scripts/, references/ and assets/ subfolders covered in the SKILL.md format guide. Nothing about the skill itself changes. What changes is that it can now travel bundled with the MCP server it depends on, instead of you wiring the two together by hand.

That MCP piece is kept deliberately separate from the skill. The spec states MCP server configuration "MUST NOT be declared inline in plugin.json". It goes in a sibling mcp.json, with a mcpServers object naming each server and its transport (stdio, streamable-http, or sse). If you've read the Agent Skills vs MCP comparison, this is that exact split (skill as procedure, MCP as live access) formalised into one packaging format rather than something you assemble yourself.

Who's actually behind it, and who isn't

The Agent Plugins Technical Steering Committee, per the spec repository's own MAINTAINERS.md, is five named individuals, each representing one company:

The project's GOVERNANCE.md is specific that "no single vendor may control a majority of Core Maintainer seats" and that governance roles belong to individuals, not the companies they work for. That's a deliberate, and by now familiar, structure for a cross-vendor spec. It's roughly the same posture Agent Skills itself took when Anthropic published it as an open standard in late 2025, rather than keeping it Claude-specific.

Anthropic is not currently on that list. Neither MAINTAINERS.md nor GOVERNANCE.md nor the spec's FUTURE_CONSIDERATIONS.md mentions Claude, Anthropic or Claude Code anywhere. That's worth stating plainly on a site that mostly covers Claude tooling: as of this writing, Agent Plugins is an OpenAI/Amazon/Microsoft/Cursor/Vercel effort that Claude Code has not joined, and there's no confirmed timeline for whether or when it will.

Don't confuse this with Claude Code's existing "plugins"

Here's the genuinely confusing part. Anthropic already ships something called Claude Code plugins, bundles of slash commands, subagents, MCP servers and hooks that install with one command, documented at claude.com/blog/claude-code-plugins. That feature predates Agent Plugins 1.0.0 and is entirely unrelated to it beyond sharing the word "plugin." Claude Code plugins are Anthropic's own packaging mechanism for Claude Code specifically. Agent Plugins is the new, cross-vendor spec described in this article, built around SKILL.md and MCP, and not (currently) implemented in Claude Code at all.

If you see "plugins" mentioned in a Claude Code context, it's almost certainly the older, Claude-specific feature, not the standard covered here. Check which one a given article, changelog entry or tool actually means before assuming they're the same thing.

What's actually shipped, verified

It's easy for a five-company press moment to outrun what anyone can actually install. Here's the distinction between what this site could directly confirm and what's reported elsewhere.

Confirmed directly, from OpenAI's own release notes: Codex CLI version 0.147.0, released 7 August 2026, added the ability to "install portable Agent Plugins and search across local, personal, workspace, and remote plugin catalogs," plus a related feature to "import Cursor-managed skills and synchronize changes to imported Claude and Cursor conversations without creating duplicates." That's a real, working implementation, one day after the spec's publication.

Reported by multiple independent outlets, not independently verified by this site: coverage of the announcement lists VS Code, Cursor, GitHub Copilot, ChatGPT and Amazon's Kiro as supported or announced-for clients, with Google reported to have joined core maintenance on launch day. This site's research could not reach cursor.com, vercel.com or several of the press write-ups directly to confirm those claims first-hand, so treat that list as well-corroborated but unverified by us. Check the client's own changelog before you plan around it.

A worked example: bundling a skill with the server it depends on

The clearest way to see what a plugin manifest actually buys you is a case where a skill is genuinely useless without a specific MCP server. Say you maintain a skill that reviews pull requests against your internal ticketing system, and it depends on an MCP server exposing a get_ticket tool. Distributed the old way, you'd hand someone two separate sets of instructions: clone the skill, then separately set up and configure the MCP server, then hope they wire the two together correctly. As an Agent Plugin, it's one folder:

pr-ticket-review/
├── plugin.json
├── mcp.json
└── skills/
    └── ticket-review/
        └── SKILL.md

// plugin.json
{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "pr-ticket-review",
  "version": "1.0.0",
  "description": "Reviews pull requests against linked tickets before merge.",
  "license": "MIT"
}

// mcp.json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "mcpServers": {
    "ticketing": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "ticketing-mcp-server"]
    }
  }
}

skills/ticket-review/SKILL.md inside that folder is written exactly the way a standalone skill already is: the same name and description frontmatter, the same markdown instructions, telling the agent to use the get_ticket tool as part of its documented review process. A client that supports Agent Plugins installs the whole folder in one step and has both the procedure and the access it depends on, correctly wired, without the installer having to guess how they relate.

Does this change how you should package a skill?

Not for most people, not yet. If a skill you're writing has no MCP server attached (the common case, since most published skills are pure instructions with no external dependency), there's nothing to gain from wrapping it in a plugin.json. Keep shipping it as a plain folder with SKILL.md at the root, the way installing a skill already works across every agent in this ecosystem.

Where a plugin manifest earns its complexity is the specific case Agent Plugins was built for: you maintain a skill that only makes sense paired with a particular MCP server, and you're tired of writing separate setup instructions for "clone the skill, then also configure this server, then connect the two." Bundling both under one plugin.json, with the server declared in mcp.json, is a real reduction in that specific kind of setup friction, assuming your target agent actually reads plugin manifests, which today means Codex CLI and, per unverified reports, a short list of others.

Plain SKILL.md skill vs Agent Plugin, at a glance

The two aren't really in competition, any more than a zip file competes with the files inside it. A plugin's skills/ directory is standalone skills, unchanged. The manifest just gives you a way to also ship the MCP server they need, and to have a client discover the pairing automatically instead of you documenting it in a README and hoping the reader gets both steps right.

A short timeline, for context

Given how fast this moved, it's worth being precise about the sequence, since "released" and "supported everywhere" are easy to conflate in coverage of a multi-vendor announcement:

• 6 August 2026: Agent Plugins 1.0.0 published to github.com/agentplugins/agent-plugins-spec, with the five-company Technical Steering Committee named above.
• 7 August 2026: Codex CLI 0.147.0 ships the first confirmed client implementation: installing plugins, searching plugin catalogs, and importing Cursor-managed skills.
• As of 12 August 2026: this is the state this article can verify directly. Other clients may have shipped support in the days since; check each vendor's own changelog for anything more recent than that date.

That's less than a week of real-world existence at the time of writing. Treat any claim about broad ecosystem support, including the reported-but-unverified client list above, as provisional until you can check a vendor's own release notes yourself.

The bigger pattern

This is the second major packaging effort to sit on top of SKILL.md since Anthropic published it as an open standard in late 2025. The first was the ecosystem of installers like the skills CLI that grew up around plain skill folders. Agent Plugins is a more formal attempt at the same underlying goal: reduce the friction of distributing an agent capability across more than one vendor's tooling.

Whether it becomes as universally read as SKILL.md itself depends on adoption this site can't predict. A five-company steering committee is a strong start, but Claude Code's absence from it is a real gap given how much of this ecosystem currently runs on Claude tooling. What's genuinely useful to know today: nothing about it threatens or deprecates a plain SKILL.md skill, the format skills already use inside a plugin is unchanged, and the one thing you can rely on right now, verified directly, is that it works in Codex CLI 0.147.0 and later.

For the format a plugin's skills/ directory actually contains, see the SKILL.md format explained. For how skills and MCP divide responsibility regardless of packaging, see Agent Skills vs MCP. And for what's confirmed to support the underlying skill format today, independent of this new packaging layer, the full list is at getclaudeskills.com/platforms.

Facts in this article were verified directly against the Agent Plugins spec repository on GitHub and OpenAI's own Codex CLI release notes on 12 August 2026. Claims attributed to press coverage rather than a vendor's own page are marked as such above; several vendor domains (cursor.com, vercel.com) were unreachable from this site's research environment at the time of writing.