Agent Plugins 1.0.0 is a portable package format for agent skills and MCP servers, published by Vercel on August 6, 2026 with a steering committee that includes core maintainers from Amazon, Cursor, Microsoft, OpenAI and Vercel (agent-plugins.org). Its launch client list reads "ChatGPT and Codex, Cursor, GitHub Copilot, Kiro, VS Code" (Vercel changelog). Claude Code is not on it.
Claude Code is also not mentioned anywhere on the standard's own compatible clients page, which I checked character by character on October 12, 2026: zero mentions of Claude. That page lists VS Code, Cursor, GitHub Copilot, ChatGPT and Codex, Kiro, Hermes Agent and OpenClaw.
The question the standard leaves open is the one people type into a search box: does this work in Claude Code, and what exactly loads where. This page answers it with the real files, the real commands and the real errors, all read from the vendors on October 12, 2026, and it starts with a plugin you can validate in under a minute.
The standard's manifest is a `plugin.json` at the plugin root. Skills live in `skills/`, one directory each, and every directory holds a `SKILL.md`. Create both files:
mkdir -p reports-plugin/skills/summarize cat > reports-plugin/plugin.json <<'EOF' { "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json", "name": "reports-plugin", "version": "1.0.0", "description": "Summarize a report directory into a short brief", "license": "MIT" } EOF cat > reports-plugin/skills/summarize/SKILL.md <<'EOF' --- name: summarize description: Summarize the reports in this directory into a short brief. --- # Summarize Read the files in this directory and write a five-line brief. EOF
Now validate it against the standard's own published schema, which is the same check a conforming client performs before it loads anything:
curl -sO https://agent-plugins.org/schemas/1.0.0/plugin.schema.json npx --yes ajv-cli@5 validate --spec=draft2020 \ -s plugin.schema.json \ -d reports-plugin/plugin.json
Run on October 12, 2026, that prints one line:
reports-plugin/plugin.json valid
The plugin is a directory with a manifest that names it, and the client discovers its components from fixed locations instead of reading them from the manifest.
Three hosts, three conventions, and the manifest location decides which one you get.
Cursor is the only host in this table that reads both conventions, and it reads them by location: a plugin that conforms to the Agent Plugins specification loads in Cursor, and its own format loads the larger component set. One detail bites the portable path in Cursor, in the vendor's words: Cursor does not expand the standard's `${PLUGIN_ROOT}` and `${PLUGIN_DATA}` variables in `mcp.json`.
Claude Code reads only its own location. The manifest is `plugin.json`, it goes inside a `.claude-plugin/` directory, and that directory holds nothing else. The skills, agents and hooks sit at the plugin root next to it. If you drop a portable plugin into Claude Code unchanged, the client is looking for a file one directory away from where you put it.
There is a second, quieter difference. In the standard, `plugin.json` cannot override component locations and cannot carry inline component configuration. Cursor's native manifest does exactly that, with a `skills` field pointing at a path, alongside fields the standard does not define at all.
The standard's manifest is small. This one is committed to Cursor's own plugin repository, added on October 12, 2026 in the commit "add Agent Plugins v1 root manifest (#576)" (cursor/plugins):
{ "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json", "name": "pstack", "version": "0.15.20", "description": "if you want to go fast, go deep first. pstack helps you write less, but higher quality code. rigorous agent workflows you can parallelize with confidence.", "author": { "name": "Lauren Tan" }, "homepage": "https://github.com/cursor/plugins/tree/main/pstack", "repository": "https://github.com/cursor/plugins", "license": "MIT", "keywords": ["pstack", "poteto-mode", "workflow", "principles", "agent-style", "subagents", "unslop"] }
The same directory in the same repository also carries a `.cursor-plugin/plugin.json`, which is why that plugin loads in Cursor with the full component set while remaining portable to any other conforming client. One plugin, two manifests, and the portable one is the smaller.
Cursor's native manifest adds display and packaging fields, taken from the plugin named `teaching` in the same repository:
{ "name": "teaching", "displayName": "Teaching", "version": "1.0.0", "description": "Skill mapping, practice plans, and learning retrospectives.", "author": { "name": "Cursor", "email": "plugins@cursor.com" }, "homepage": "https://github.com/cursor/plugins", "repository": "https://github.com/cursor/plugins", "license": "MIT", "logo": "assets/avatar.png", "keywords": ["teaching", "study-plan", "practice", "feedback", "mentorship"], "category": "utilities", "tags": ["teaching", "education", "practice"], "skills": "./skills/" }
Claude Code's manifest is the smallest of the three in its own documentation example, and the field that matters most is the name, because it becomes the prefix on everything the plugin provides:
{ "name": "my-first-plugin", "description": "A greeting plugin to learn the basics", "version": "1.0.0", "author": { "name": "Your Name" } }
Saved as `my-first-plugin/.claude-plugin/plugin.json`, that is a working Claude Code plugin before you add a single component (create a plugin).
The standard ships a JSON Schema, and the schema is strict in a way that catches people in the first five minutes. It requires exactly two fields, `$schema` and `name`, it fixes `$schema` to one accepted value, and it sets `additionalProperties` to false, so a field the standard does not define fails validation. `name` is 1 to 64 characters and has to match this pattern:
^(?!.*(?:--|\.\.))[a-z0-9](?:[a-z0-9.-]*[a-z0-9])?$
Lowercase alphanumeric at both ends, no consecutive hyphens, no consecutive periods. `my-plugin`, `acme.tools`, `lint3r` and `a` pass. `My-Plugin`, `-start`, `has--double` and `too.many..dots` fail. The spec states the rule and the schema enforces it, which means a client that validates the manifest rejects an otherwise perfect plugin because one letter is uppercase.
Claude Code has its own distribution layer on top of its own format: marketplaces, which are catalogs defined by a `.claude-plugin/marketplace.json` file in a repository. Anthropic publishes three general-purpose ones, and the names matter because you install with the name, not the URL.
The official marketplace is added for you the first time you start an interactive session, unless a managed policy or `CLAUDE_CODE_DISABLE_OFFICIAL_MARKETPLACE_AUTOINSTALL` blocks it. On a fresh machine where no interactive session has run, a script has to add it explicitly, which is the step that breaks unattended setups:
claude plugin marketplace add anthropics/claude-plugins-official claude plugin marketplace add anthropics/claude-plugins-community claude plugin install commit-commands@claude-plugins-official --scope project claude plugin list claude plugin marketplace list
A successful marketplace add prints this line:
Successfully added marketplace: claude-plugins-official
The scope argument is where teams get surprised. User scope is the default. `--scope project` writes the entry into `.claude/settings.json`, which you commit, and that entry enables the plugin for everyone in the repository without downloading it to their machines. Every collaborator still runs the install once for themselves.
Auditing what you have is a three-command habit:
claude plugin list claude plugin validate ./reports-plugin claude --debug
`claude plugin validate` takes a plugin directory and reports schema-level problems in its components, which is the fastest way to find a broken MCP server entry that never appears in the interface. The vendor documents one case explicitly: an entry in `.mcp.json` that fails the schema is dropped silently, with the reason written only to the debug log.
Removing a plugin leaves more behind than people expect:
claude plugin uninstall reports-plugin --scope project ls ~/.claude/plugins/cache/
Cached files stay under `~/.claude/plugins/cache/` for 14 days before a background sweep removes them. Removing the marketplace as well uninstalls every plugin you installed from it, which is the correct move when you have stopped trusting the owner rather than one plugin.
The portable manifest and the Cursor manifest can describe the same directory. This builds a plugin that loads in both, using the fixed locations the standard defines and the extra manifest Cursor wants:
mkdir -p dual-plugin/skills/summarize dual-plugin/.cursor-plugin cat > dual-plugin/plugin.json <<'EOF' { "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json", "name": "dual-plugin", "version": "1.0.0", "description": "Summarize a directory of reports", "license": "MIT" } EOF cat > dual-plugin/.cursor-plugin/plugin.json <<'EOF' { "name": "dual-plugin", "displayName": "Dual Plugin", "version": "1.0.0", "description": "Summarize a directory of reports", "author": { "name": "Your Name" }, "license": "MIT", "skills": "./skills/" } EOF printf -- '---\nname: summarize\ndescription: Summarize the reports in this directory.\n---\n\n# Summarize\n\nRead the files and write a five-line brief.\n' \ > dual-plugin/skills/summarize/SKILL.md
Then prove both, rather than assuming:
npx --yes ajv-cli@5 validate --spec=draft2020 \ -s plugin.schema.json \ -d dual-plugin/plugin.json plutil -lint dual-plugin/.cursor-plugin/plugin.json 2>/dev/null \ || python3 -m json.tool dual-plugin/.cursor-plugin/plugin.json > /dev/null find dual-plugin -type f | sort
The output you are looking for, in order:
dual-plugin/plugin.json valid
dual-plugin/.cursor-plugin/plugin.json dual-plugin/plugin.json dual-plugin/skills/summarize/SKILL.md
The structure check is the part people skip: because the standard discovers components from fixed locations and forbids inline configuration, a plugin whose skill sits in `dual-plugin/skill/` instead of `dual-plugin/skills/` validates clean and then loads nothing. A manifest that validates clean says nothing about whether the components are in the right place.
Manifest validation failures come from the published schema, and these three were produced on October 12, 2026 by running the vendor's schema, unmodified, against deliberately broken files. This is the output you can reproduce yourself.
A field the standard does not define, and a name with an uppercase letter:
{ "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json", "name": "My-Plugin", "version": "1.0.0", "display_name": "My Plugin" }
bad/my-plugin.json invalid [ { instancePath: '', schemaPath: '#/additionalProperties', keyword: 'additionalProperties', params: { additionalProperty: 'display_name' }, message: 'must NOT have additional properties' }, { instancePath: '/name', schemaPath: '#/properties/name/pattern', keyword: 'pattern', params: { pattern: '^(?!.*(?:--|\\.\\.))[a-z0-9](?:[a-z0-9.-]*[a-z0-9])?$' }, message: 'must match pattern "^(?!.*(?:--|\\.\\.))[a-z0-9](?:[a-z0-9.-]*[a-z0-9])?$"' } ]
A manifest missing the schema field, and one pointing at a version that does not exist:
bad/missing-schema.json invalid [ { instancePath: '', schemaPath: '#/required', keyword: 'required', params: { missingProperty: '$schema' }, message: "must have required property '$schema'" } ]
bad/wrong-version.json invalid [ { instancePath: '/$schema', schemaPath: '#/properties/$schema/const', keyword: 'const', params: { allowedValue: 'https://agent-plugins.org/schemas/1.0.0/plugin.schema.json' }, message: 'must be equal to constant' } ]
The third one is the check that matters when the standard moves to 1.1.0. The spec says a client that finds an unsupported version must reject the plugin and should report it.
Claude Code's errors are messages rather than schema bodies, and the vendor documents them with their fixes. These are quoted from the plugin troubleshooting page, read October 12, 2026:
error: unknown command 'add'
That one means you typed `claude plugin add `. The commands are `claude plugin marketplace add ` to add a catalog and `claude plugin install @` to install from it.
error: unknown option '--project'
The scope flag is `--scope project`, not `--project`. The corrected line is `claude plugin install @ --scope project`.
corrupt manifest file JSON parse error:
The manifest is not valid JSON. A trailing comma in `plugin.json` produces this.
N errors during load. Run /plugin for details.
Open the Errors tab in `/plugin`. Each entry pairs the message with the fix, which is why the documented next step is a panel and not a log file.
The plugin couldn't be loaded
Same route: the Errors tab carries the reason.
Invalid MCP server config for "<server>": <error>
Or the server is listed and never connects. One case has no visible error at all: a server entry in `.mcp.json` that fails the schema is dropped with the reason written only to the debug log, and `claude plugin validate` on the plugin directory is the way to see it without loading anything.
Two failure modes are not errors and will not be reported to you.
The first is the duplicate install. Anthropic's own documentation tells you to install shared plugins from the official marketplace "so you don't have two copies installed", and the largest skill repository on GitHub puts the same warning in its install section: pick one method per agent, because installing both gives you every skill twice. A plugin installed from two marketplaces, or a skill installed both as a plugin and copied into the project, shows up twice in the context and does the work twice.
The second is the silent layout mismatch. A valid manifest with components in the wrong directory passes every check you are likely to run and contributes nothing.
Claude Code's security documentation states the risk in one line, and it applies to every host in this guide: a plugin can carry content that runs code on your machine with your user privileges and content that enters the model's context as instructions. Both arrive from a third party.
The review list that follows from that is short enough to use.
Who publishes the catalog, and who wrote the plugin. A marketplace name tells you who publishes the catalog, not what each plugin in it does, which is why the same review applies to Anthropic's official marketplace as to anyone else's. Most of what the official marketplace lists comes from partners and other authors rather than from Anthropic.
What the plugin reads and with what credentials. A plugin that reads environment files, shells out, or talks to a service is asking for your access. Anything that touches production gets reviewed the way you review a dependency, because that is what it is.
What happens on update. With auto-update on for a marketplace, plugins update in the background, so the files you reviewed on Monday are not the files that run on Friday. Turning auto-update off per marketplace controls how much unreviewed code you accept each week.
What removal actually removes. Uninstall leaves cached files for 14 days and can leave the marketplace behind. Trusting the marketplace is a separate decision from trusting the plugin, and both have an undo.
Where the side effects live. The generic version of this rule is the one we publish under gating risky tool calls: the agent proposes, your code decides, and the plugin's hooks are the part that runs without asking.
For a wider comparison of what official and community plugin catalogs actually contain, the plugins guide covers the star counts, the maintenance signals and the ones that are abandoned. The complete Jev guide indexes the rest of that cluster, and how to install Jev uses the same validate-then-trust habit this page applies to manifests. If your team is deciding where human review belongs in an agent pipeline, bounded permissions and human approval is the longer argument, and the Claude Code skill tutorial is what this looks like when the plugin is already installed and doing work.
Does an Agent Plugins 1.0.0 plugin work in Claude Code?
Not as shipped. Claude Code reads `.claude-plugin/plugin.json` and the standard puts `plugin.json` at the plugin root. The content is portable, the manifest location is not, so a portable plugin needs a second manifest to load there.
Can one directory serve both hosts?
Yes, and Cursor's own repository does it: a root `plugin.json` for the portable format and a `.cursor-plugin/plugin.json` for the native one. Both describe the same skills and MCP servers.
Why did my plugin validate and then load nothing?
Almost always the layout. The standard discovers skills from `skills/` and MCP servers from `mcp.json`, and the manifest cannot override those locations, so a valid manifest with components elsewhere is a valid empty plugin.
Is the official marketplace a guarantee?
No. It is a catalog. Anthropic maintains a small set of plugins in it and most of the rest comes from partners, so the review is per plugin rather than per catalog.
How do I remove a plugin I no longer trust?
`claude plugin uninstall ` at the scope you installed it, then delete `~/.claude/plugins/cache///` if you do not want to wait 14 days, and remove the marketplace if you do not trust its owner either.
Does any of this change weekly?
The standard shipped version 1.0.0 on August 6, 2026, Cursor committed a root manifest in its own repository on October 12, 2026, and Nous Research published an official plugin repository on October 10, 2026. Re-read the spec page before you ship a plugin against it.
[1] Agent Plugins, specification, read October 12, 2026. The manifest definition, the two component types and their fixed locations, the name rules with valid and invalid examples, and the rule that a missing component location is not an error.
[2] Agent Plugins, compatible clients, read October 12, 2026. VS Code, Cursor, GitHub Copilot, ChatGPT and Codex, Kiro, Hermes Agent and OpenClaw, with the MCP transports each supports. The page contains no mention of Claude or Claude Code.
[3] Agent Plugins, plugin schema 1.0.0, read October 12, 2026. `additionalProperties` false, required `$schema` and `name`, the name pattern, and the `$schema` constant. Used to produce every validation output in this post.
[4] Vercel, Introducing Agent Plugins 1.0.0, August 6, 2026. The root `plugin.json` format and the launch client list quoted above.
[5] Cursor, plugins reference, read October 12, 2026. The two supported formats, their manifest locations, the components each loads, and the note that Cursor does not expand `${PLUGIN_ROOT}` and `${PLUGIN_DATA}` in `mcp.json`.
[6] Cursor, plugins overview, read October 12, 2026. Plugin structure, publishing and MCP install links.
[7] Claude Code, plugins overview, read October 12, 2026. The manifest at `.claude-plugin/plugin.json` and the component list.
[8] Claude Code, install and manage plugins, read October 12, 2026. Install commands, the three scopes, the project-scope behaviour, the `Successfully added marketplace:` output and the official-marketplace bootstrap on a fresh machine.
[9] Claude Code, plugin security and trust, read October 12, 2026. What an installed plugin can do with your privileges, background auto-update, the 14-day cache after uninstall, and removal of a marketplace.
[10] Claude Code, troubleshoot plugins, read October 12, 2026. Every error string quoted in the failure section, with its documented fix.
[11] GitHub, cursor/plugins, read October 12, 2026. The real `pstack/plugin.json` and `teaching/.cursor-plugin/plugin.json` manifests reproduced here, and the commit of October 12, 2026 titled "add Agent Plugins v1 root manifest (#576)". The repository shows 11,006 stars and 1,063 forks on that date and appears in GitHub Trending weekly.
[12] GitHub, anthropics/claude-plugins-official, read October 12, 2026. The official marketplace catalog file, `.claude-plugin/marketplace.json`, and the marketplace names used in the install recipe.
Maxpertise is an AI-native engineering company. We embed native AI engineers inside your team, live in about 10 days. Please enable JavaScript to view the site, or email contact@maxpertise.net.