Agent Plugins 1.0: One Plugin, Nine Clients in 2026

Agent Plugins 1.0.0 is an open, vendor-neutral specification for packaging Agent Skills and MCP servers into a single portable directory that any compatible AI agent client can load. Published on August 6, 2026, it lists nine compatible clients as of August 13.¹²³⁴

TL;DR

Five companies whose teams had each been solving the same packaging problem separately agreed on one answer. Amazon, Cursor, Microsoft, OpenAI, and Vercel published Agent Plugins 1.0.0 on August 6, 2026, and Google announced the same day that it is joining as a Core Maintainer.¹²

A plugin is now just a directory: a plugin.json manifest, a skills/ folder, and an mcp.json file.³

The spec is deliberately tiny. It defines exactly two component types and no install mechanism, no permission model, no sandboxing, and no signature verification — all of which the project names openly as future work.²³⁵

Two details are worth pausing on. The specification is still labelled a Working Draft, and the Lead Core Maintainer — the charter's designated tie-breaker for unresolved disputes — is Vercel's representative, at the company that wrote the initial draft.³⁶⁷

What You'll Learn

• What Agent Plugins actually is, and how it differs from MCP and Agent Skills
• What the plugin directory contains and which fields the manifest requires
• Who governs the spec, and which company is conspicuously not on the roster
• A transport-support gap across the nine compatible clients that can silently drop an MCP server
• What version 1.0.0 deliberately leaves out, in the project's own words

What Agent Plugins actually is

Agent Plugins is a packaging format, not a protocol and not a marketplace. It standardises the box, not the contents.

The problem it solves is narrow and real. Agent Skills were already portable, and MCP servers were already portable — but the wrapper around them was not, so authors forked the same components for each client and watched the copies drift.²

Google's announcement puts it bluntly: "The core problem isn't the components. It's the manifest."²

So the format is small on purpose. Version 1.0.0 standardises exactly two component types — skills and MCP servers — and the spec states that other proposed types such as commands, hooks, agents, rules, and LSP servers "remain too client-specific for a stable portable contract."³

How it relates to MCP and Agent Skills

These three are layers, not competitors.

Agent Plugins sits above both and defers to both. Skills inside a plugin "MUST conform to the Agent Skills specification," and MCP wire behaviour remains governed by the MCP spec.³

What's in the box

An Agent Plugin is a directory with a required manifest and optional components in fixed locations.³

my-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
├── mcp.json
└── com.example.client/

The manifest is close to empty. Only two fields are required — $schema and name — which makes a valid plugin about a minute of work.²³

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

The manifest schema is closed. Only ten top-level fields are permitted, and clients must report and ignore anything else rather than inventing meaning for it.³

Crucially, plugin.json cannot relocate components or declare them inline. Skills are found in skills/ and MCP servers in mcp.json, full stop — there is no discovery path to configure and no precedence order to learn.²³

That last reverse-domain directory, com.example.client/, is the escape hatch. It is a namespace owned entirely by one client, and clients that don't recognise it ignore it.²³

The transport gap worth checking before you ship

Here is something the launch coverage skipped, and it matters if you publish a plugin.

The spec requires a client that supports MCP servers to implement at least one of stdio or streamable-http, and says it should support both. Support for the legacy HTTP+SSE transport is explicitly OPTIONAL.³

That optionality shows up unevenly across the nine clients currently listed as compatible. The table below is compiled from each client's entry on the official compatible-clients page as of August 13, 2026 — the list is growing, so check it before you rely on this.⁴

Six of the nine support all three transports. Three — ChatGPT & Codex, Hermes Agent, and NanoClaw — do not list legacy SSE.⁴

That is a third of the compatible clients, and it includes OpenAI's, so it is not a rounding error.

The consequence is specific. If your mcp.json declares a server with "type": "sse", a client that doesn't support that transport must skip that server and carry on loading everything else.³

Your plugin will not fail. It will simply come up with one fewer server on those clients, and the spec asks the client to report it rather than guaranteeing a fallback — Agent Plugins defines no fallback behaviour if the declared transport fails.³

For plugin authors the practical rule is to prefer streamable-http for remote servers unless you have a reason not to. Legacy SSE is portable to most clients, not all of them.

Who governs it, and who isn't on the list

The Technical Steering Committee is the set of Core Maintainers plus a Lead Core Maintainer.⁶ The project's MAINTAINERS file lists five:⁷

Google announced on launch day that it is joining that group as a Core Maintainer, represented by Kevin Hou. As of August 13, 2026, the MAINTAINERS file still lists the five above and does not yet include a Google representative.²⁷

The charter is unusually explicit about neutrality. Governance roles "are held by individuals, not organizations," no seats are reserved for specific companies, and "no single vendor may control a majority of Core Maintainer seats."⁶

Now the part that makes this interesting.

Agent Plugins 1.0.0 standardises exactly two component types, and both of them originated at Anthropic. Anthropic published the Agent Skills specification as an open standard on December 18, 2025, and donated MCP to the newly formed Agentic AI Foundation under the Linux Foundation on December 9, 2025.¹⁰¹¹¹²

No Anthropic-affiliated maintainer appears on the Agent Plugins roster.⁷ Given the charter's individuals-not-organisations rule, that is a description of the current list rather than evidence of exclusion — but it does mean the packaging layer for both formats is being versioned by a committee Anthropic is not currently represented on.

Anthropic is not absent from the surrounding ecosystem, though. It co-founded the Agentic AI Foundation alongside Block and OpenAI, where MCP now sits as a founding project under neutral governance.¹⁰¹¹

Claude Code is likewise not listed among the compatible clients as of August 13, 2026.⁴ Anthropic's Agent SDK documents its own plugin system that loads skills, MCP servers, hooks, commands, and agents from local directories.¹³

Where the deciding vote sits

One more governance detail deserves attention. The charter designates the Lead Core Maintainer as the "final technical decision-maker when consensus cannot be reached," as TSC chair by default, and as the person who publicly confirms or declines nominations for new Core Maintainers.⁶

That role is held by Jonathan Hefner of Vercel — the company that released the initial specification draft and convened the working group.¹⁷

Nothing about that is improper, and the charter constrains it. Removing a Lead Core Maintainer takes a 75% super-majority of the other Core Maintainers, and amending the charter requires a two-thirds vote of the entire TSC.⁶

But it does mean the casting vote on a format five direct competitors now depend on sits with one of them, on a spec still marked Working Draft.³⁷

What v1.0.0 deliberately leaves out

The project names its own gaps rather than quietly omitting them, which is more than most launches manage.²

Version 1.0.0 defines no install mechanism, no distribution protocol, no permission model, no sandboxing requirements, no trust or provenance verification, and no user experience.²³

The project's future-considerations document expands the list: permission declarations, cryptographic signature verification, attestation chains, secret handling, allowlist and blocklist policies, audit-event schemas, dependency resolution, and a conformance test harness are all recorded as possible future work and explicitly "not committed for inclusion."⁵

Two of those absences have immediate security consequences.

First, secrets are not a portable concept here. The spec states plainly that configured env values and HTTP headers are "visible package data, not a portable secret mechanism," and that plugins "MUST NOT embed credentials or other secrets" in either.³

Second, there is no portable auth. Agent Plugins v1 "defines no OAuth configuration or portable credential-reference fields" — authorization discovery, user interaction, and credential storage are all client-managed.³

The spec does carry real safety requirements at the filesystem layer. Clients must reject package paths that resolve outside the plugin root, and plugin-relative paths must begin with ./ and stay inside the root after resolution.³

But those rules govern access to files the package supplies. They explicitly "do not sandbox a plugin subprocess."³

That gap lands in a year that has not been kind to agent tooling. Check Point researchers disclosed eleven vulnerabilities across major agent frameworks in early August, and CISA added a critical Langflow remote-code-execution flaw — CVE-2026-9198, CVSS 9.8 — to its Known Exploited Vulnerabilities catalog the same week, a reminder that agent framework code is now attacker-facing middleware.¹⁴¹⁵

A portable package format that travels further and faster than before, with signature verification still on the roadmap, is a distribution surface worth threat-modelling early.

What's actually shipping today

Support is not theoretical. Two vendors shipped at launch.

AWS made the AWS Agent Toolkit compatible and rolled Agent Plugins support into Kiro Powers. The toolkit bundles 30-plus curated skills across multiple plugins covering Lambda, S3, DynamoDB, and CDK.¹

Google shipped support in two products the same day: Agents CLI, which packages its agent-building and evaluation skills, and the Data Agent Kit, whose plugins connect to BigQuery, Spanner, and Cloud SQL.²

The licensing is conventional open-source. Specification text and documentation are CC BY 4.0 and code is Apache 2.0, with the TSC able to approve alternative licences by a two-thirds vote.⁶

What this means if you build agent tooling

If you maintain a skill or an MCP server, the calculus changed on August 6.

Package once as a directory with plugin.json at the root and you reach nine clients instead of one. That is a genuine reduction in busywork, and it is the whole pitch.

But do not read a packaging standard as a safety standard. It says nothing about who may install your plugin, what it may access, or whether the copy a user installed is the copy you published.

Those are exactly the guarantees that Agent Skills already shipped without, and the same pattern is now visible one layer up. Portability arrives first; verification arrives later, if at all.

It is also worth noting how quickly this landed relative to the standards bodies. Agent Plugins went from a Vercel draft to a multi-vendor 1.0.0 with nine compatible clients listed within a week — a pace that stands in sharp contrast to agent identity work still waiting on IETF adoption.¹⁴

Fast convergence is genuinely useful. It also means the trust model is being retrofitted onto a format that is already in production, which is the harder order to do it in.

The bottom line

Agent Plugins is a good standard doing a small job well, and the restraint is the point. Five competitors converging on a single directory layout is a real achievement, and Google's same-day maintainer commitment suggests the convergence is holding.

The caveats are structural rather than technical. The spec is still a Working Draft, the casting vote sits with the vendor that wrote the draft, the two formats it packages both came from a company not currently on the roster, and every trust guarantee a package format eventually needs is listed as future work.

None of that makes it a bad bet. It makes it an early one — and worth adopting for the portability while treating installation, permissions, and provenance as problems you still own.

References