Agent Plugins Spec 1.0.0: One Plugin Folder for Every Agent

There is now a cross-vendor standard for packaging the things that extend an AI agent. The Agent Plugins spec 1.0.0 defines one portable folder: a plugin.json manifest, a skills/ directory, and an mcp.json file. Any client that implements it can read that folder and get the plugin's skills and MCP servers, with no per-client repackaging. Dream Pixel Forge now ships one, so an agent can pick up our image and video tools and the workflow that drives them from a single directory.

This matters more than a normal format announcement because of who signed it. The specification is governed by a Technical Steering Committee whose Core Maintainers come from Amazon, Cursor, Microsoft, OpenAI, and Vercel, and its charter says governance roles belong to individuals rather than companies, with no single vendor allowed a majority of seats. Five competing agent vendors agreeing on a directory layout is the interesting part.

It is also very new. The repository started in April 2026 as Vercel's Open Plugin Specification, was renamed to Agent Plugins in mid-July once the governance charter and the multi-vendor committee were in place, and 1.0.0 was marked published on July 24, 2026.

What the Agent Plugins spec actually standardizes

The spec is deliberately small. It calls itself “a small interoperability floor for the parts that can be portable across clients,” and it defines exactly two component types: skills and MCP servers. Everything else, including how a client shows a plugin to the user, stays out of scope.

A plugin is just a directory. The manifest sits at the root, and components live at fixed locations that plugin.json cannot override:

my-plugin/
├── plugin.json          # required manifest
├── skills/
│   └── summarize/
│       └── SKILL.md     # one skill per subdirectory
├── mcp.json             # MCP server configuration
└── com.example.client/  # client-specific extension namespace

The manifest schema is closed: only $schema, name, version, description, author, homepage, repository, license, keywords, and extensions are allowed, and just the first two are required. Client-specific data has to go under extensions, keyed by a reverse-domain namespace, which is how the spec keeps one vendor's fields from becoming everyone's problem.

Two details show the spec was written by people who have shipped clients. Skills are discovered only in immediate subdirectories of skills/, never by recursive search, so a large plugin cannot turn startup into a filesystem crawl. And clients must not fetch a schema over the network while loading a plugin: the $schema URL is a version identifier, not a runtime dependency. Read the normative text in the 1.0.0 specification, which marks its own status as Published.

Agent Plugins, Agent Skills, and MCP: what the agent plugin standard adds

The three specs stack rather than compete, and it is worth being precise about which does what.

• MCP defines how an agent talks to a tool server: the wire protocol and lifecycle. It says nothing about how you ship one.
• Agent Skills defines SKILL.md: YAML frontmatter with a required name and description, then Markdown instructions the agent loads when the task calls for it. Agent Plugins does not redefine this format, it points at it and says conforming skills must follow it.
• Agent Plugins is the package around both. It is the missing envelope, not a new protocol.

So if you were searching for an MCP plugin standard, this is the closest thing that exists: a standard way to distribute an MCP server together with the instructions an agent needs to use it well. The protocol was already standard. The folder was not.

Dream Pixel Forge now ships an Agent Plugins plugin

Our plugin lives at packages/agent-plugin/ in the repo. It carries the full hosted tool surface, currently 30 MCP tools covering runs, brand profile, prompt templates, model selection, reference uploads, image and video generation, vision validation, upscaling, background removal, and moodboards, plus one agent skill that teaches the workflow those tools expect:

packages/agent-plugin/
├── plugin.json
├── mcp.json
├── skills/
│   └── dpf/
│       └── SKILL.md
└── bin/
    └── dpf.js        # bundled CLI, produced by the build

Both manifests validate against the official 1.0.0 JSON schemas published at agent-plugins.org/schemas/1.0.0/. The skill is the more interesting half. A generation tool that an agent calls blind produces expensive noise, so skills/dpf/SKILL.md encodes the sequence the product actually rewards: create a run, store a concept plan, generate against that plan, then validate each result with the vision tool before showing it to the user. It also carries the rules that keep spend sane, because credits are real money and the agent should know that a video clip is not priced like a thumbnail.

That split is exactly what the spec is for. The tools alone are an API. The tools plus the skill are a colleague who has read the manual.

Why the plugin ships a proxy instead of a key

Our mcp.json does not point at our hosted endpoint directly, and the spec is the reason:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
  "mcpServers": {
    "dream-pixel-forge": {
      "type": "stdio",
      "command": "node",
      "args": ["${PLUGIN_ROOT}/bin/dpf.js", "mcp"]
    }
  }
}

Agent Plugins 1.0.0 is blunt about credentials. Configured env values and HTTP headers are “visible package data, not a portable secret mechanism,” and plugins must not embed credentials or other secrets in either. The spec defines no OAuth configuration and no portable credential-reference field at all: authorization and credential storage are the client's job in v1.

A remote streamable-http entry pointing at our API would therefore have no legal place to put your key. So the plugin bundles a small stdio proxy instead, new in dreampixel-cli 0.4.0. It speaks JSON-RPC over stdin and stdout, forwards each message to https://www.dreampixelforge.com/api/mcp with an Authorization: Bearer header, and reads the key from the machine, either the one dpf login stored or DPF_API_KEY. Nothing secret is ever in the package. The ${PLUGIN_ROOT} placeholder in args is the spec's own mechanism for referencing bundled files, expanded by the client at launch.

The key itself never travels either. As with our MCP server, dpf login mints the key locally and sends only its SHA-256 hash to the server for approval, so an approved key cannot be read back out of your account.

How to install it today

Honest version: this is a build-it-yourself install, not a marketplace click. The bundled CLI is a build artifact rather than a checked-in binary, so from a clone of the repo:

pnpm plugin:build          # bundles the CLI into packages/agent-plugin/bin/
npx dreampixel-cli login   # opens a browser, stores the key locally

That leaves packages/agent-plugin/ as a complete, self-contained plugin directory you can point a conforming client at, or copy anywhere you like. Node 20 or newer needs to be available, since the MCP entry runs node bin/dpf.js mcp. If your client does not do plugins yet, nothing is lost: the same tools are reachable as a plain MCP server in Claude Code or Cursor, or through the dpf CLI directly.

What the spec does not do yet

The 1.0.0 release is a package format and nothing more, which is a feature, but it does mean several things people expect from “plugins” are absent. The project's own future considerations document lists them plainly: there is no trust model, no permission declarations or sandboxing, no signature or provenance verification, no secrets mechanism, no dependency resolution, and no standard validator. All of those are marked as possible future work, none as committed.

Distribution is out of scope too. The spec standardizes what a plugin is, not where it comes from, so there is no registry and no install command in 1.0.0. Every client will keep its own answer to that for now.

How to use agent plugins in VS Code and other clients

Client support is the part to watch, and to not overstate. VS Code ships agent plugins in preview, gated behind the chat.plugins.enabled setting, and it expects the same shape: a plugin.json at the root, a skills/ directory, and MCP server configuration. You install from the UI or by running Chat: Install Plugin From Source from the Command Palette. Claude Code and Copilot CLI have their own converging plugin formats.

But the VS Code documentation does not currently cite the Agent Plugins specification, and neither do most client docs. What exists today is a written standard that formalizes a shape several clients had already arrived at independently, plus a governance structure for keeping them aligned. That is a good position for a spec to be in two weeks after publication. It is not the same as every client advertising conformance, and anyone telling you a plugin folder is now guaranteed portable is ahead of the evidence.

One practical warning while searching: Agent Plugins for AWS is an unrelated Amazon project that shares the name and outranks the spec for several queries. If you land on awslabs/agent-plugins, that is a collection of AWS-specific plugins, not the vendor-neutral standard at agent-plugins.org.

Why we shipped one now

Because the alternative is writing the same integration five times. We already maintain an MCP server, a CLI, and a set of instructions explaining how to use them together. Agent Plugins lets those three things travel as one unit, and the cost of adopting it was a manifest, a config file, and a directory move.

The spec text is licensed CC-BY-4.0 and the code Apache 2.0, decisions are made in public GitHub discussions, and the charter forbids any single vendor from holding a majority. Standards with that shape tend to be worth being early to. If you build agent tooling, the plugin folder is cheap to add and the format is now written down.