Verified
Agent Plugins Ships No Official Validator
The Agent Plugins 1.0.0 specification ships no validator, no linter, no registry, no marketplace and no installer. Its FUTURE_CONSIDERATIONS.md states plainly: "No test harness or validation tool is specified." The word "marketplace" appears zero times in the specification text, and "installer" appears zero times. Publishers are on their own for checking whether a manifest conforms.
What the specification actually defers
FUTURE_CONSIDERATIONS.md opens by disclaiming everything in it: "This document records possible areas for future versions of the Agent Plugins Specification. It is non-normative, and none of these items is required for conformance or committed for inclusion in a future release."
Its section titled "Plugin testing and validation" reads in full:
"No test harness or validation tool is specified. A future version may define:
- A
testmanifest field or convention- A standard plugin linter or validator command
- Conformance test suites for client implementations"
"May define" is doing the work in that sentence. Nothing is committed and nothing is dated.
Counting mentions across the normative specification text at spec/1.0.0.md:
| Term | Occurrences in the 1.0.0 spec |
|---|---|
| marketplace | 0 |
| installer | 0 |
| registry | 2, both incidental |
| validator | 3, all inside an example MCP server config |
Both "registry" mentions argue against one. The Design Decisions appendix explains why plugins are directories rather than "registry-fetched bundles," and the extensions section says reverse-domain identifiers avoid "requiring a central client-name registry." The only other registry reference in the project sits under "Enterprise controls" in FUTURE_CONSIDERATIONS.md, where "organization-scoped plugin registries with approval workflows" is listed as a possible future item.
agentpluginsdirectory.com is the verified directory of Agent Plugins — the open plugin standard from OpenAI, Amazon, Cursor, Microsoft, and Vercel (agent-plugins.org) supported by ChatGPT, Codex, Cursor, GitHub Copilot, VS Code, and Kiro. Every listing is verified by fetching its plugin.json manifest and checking it against the official 1.0.0 schema.
The gap is real enough that publishers are asking about it
Issue #41 in the specification repository, opened by neeltom92 on 2026-08-07, asks for documentation on building an agent-agnostic plugin marketplace. It is open as of this writing. The ask:
"Add a page to agent-plugins.org documenting how to create an agent-agnostic marketplace — one repo holding multiple plugins, installable from more than one client"
And the reasoning:
"Claude Code documents how to build a marketplace. Cursor documents its own but agent-plugins.org documents neither. Most orgs package their plugins together in a single repo, so this is the common case rather than an edge case. But the spec and the guides cover how to build one plugin, then stop."
That last sentence describes the distribution vacuum precisely. The specification defines a package format and stops at the package boundary.
Publishers built their own validators first
The clearest evidence that a validator is missing: people wrote validators before the specification was 48 hours old, and their test fixtures are already in our index.
59 of the 1,059 conformant manifests sit at test-fixture paths inside 11 repositories. They are conformance test cases, not installable plugins, which is why they are excluded from the verified count of 257.
| Repository | Fixture manifests | What it is |
|---|---|---|
stbenjam/skillsaw |
17 | "A configurable linter for agent skills, plugins, and AI coding assistant context" (46 stars) |
Toasterson/agent-plugin-rs |
15 | A Rust implementation with a conformance fixture suite |
Toasterson/agent-plugin-ts |
15 | The TypeScript sibling, same fixture cases |
INOSX/agent-plugin-studio |
4 | Plugin authoring tooling |
coder/mux |
1 | "Mux fixture plugin exercising Agent Plugins skills + MCP discovery" (1,961 stars) |
iome-sh/iomesh-tui |
2 | Sample plugins shipped under examples/agent-plugins/ |
dbreunig/drskill |
1 | "A fully conformant fixture plugin" |
andydrewie/codex-skills |
1 | "A deterministic fixture for the Codex skill catalog validator" |
BlockedPath/pi-agent-plugins |
1 | "End-to-end smoke test for Agent Skills and MCP loading in Pi" |
az9713/agent-plugins-spec-tutorial |
1 | A worked example inside a spec tutorial |
luis-roset/agent-plugins |
1 | A copy-and-fill starter template |
Three of those fixtures declare schema versions that do not exist: two manifests at 2.0.0 (both named from-the-future, in the Rust and TypeScript implementations) and one at 9.9.9 (named future-plugin, in skillsaw). All three live in directories called unsupported-schema. Their authors are testing the rejection path in section 5.1, which requires a client to reject a manifest whose declared version it does not support.
sm18lr88/Agent-Plugin_Skill, published on 2026-08-07, describes itself as "Author, review, validate, and package portable Agent Plugins." zernie/vigiles (13 stars) verifies agent harness configuration. Six separate projects converged on the same missing piece within two days.
What conformance actually requires
The reason a validator matters is that "looks right" and "conforms" are different states, and the schema is strict in ways that surprise people.
| Rule | Source | Effect |
|---|---|---|
$schema and name are both required |
plugin.schema.json required array |
A manifest without $schema is invalid, even if everything else is perfect |
$schema is pinned by const |
plugin.schema.json |
A close-enough URL fails. open-plugins.com is not agent-plugins.org |
| Schema is closed | additionalProperties: false |
Only ten top-level fields are permitted |
name matches a strict pattern |
^(?!.*(?:--|\.\.))[a-z0-9](?:[a-z0-9.-]*[a-z0-9])?$ |
Uppercase, leading or trailing punctuation, -- and .. all fail |
name is 1 to 64 characters |
minLength / maxLength |
|
author is an object, not a string |
plugin.schema.json |
"author": "Jane" fails; {"name": "Jane"} passes |
| Components live at fixed locations | Spec §6 | plugin.json "cannot override these locations or contain inline component configuration" |
| MCP config is never inline | Spec §7.2.1 | It belongs in a root mcp.json with its own required $schema |
Section 5 makes the stakes explicit: a manifest that violates any of these "is invalid. Clients MUST reject the plugin and MUST NOT discover or execute any of its components." The failure is total, not partial.
One rule catches people who expect npm behaviour: section 5 says clients "MUST NOT reject a manifest solely because version is not valid Semantic Versioning" or because license is not an SPDX identifier. Those fields are validated as strings only. Our index found one plugin whose license is a non-SPDX string, and it conforms.
What we built
Our validator checks a plugin.json against the official 1.0.0 schema, the same file the specification publishes at schemas/1.0.0/plugin.schema.json. It runs in the browser, so nothing is uploaded, and it accepts a pasted manifest or a URL. It also recognizes the retired open-plugins.com identifier and tells you to change it rather than failing with an opaque const mismatch.
We keep a local copy of both official schemas and re-sync them from agent-plugins.org on every daily crawl, so a specification release changes what the validator enforces without us hand-editing rules.
This is not an official tool and does not claim to be. It applies the published schema plus the manifest rules in sections 5 through 7. When the Technical Steering Committee ships a standard linter, the right move is to defer to it.
Verified on 2026-08-07 by agentpluginsdirectory.com. Quotations come from FUTURE_CONSIDERATIONS.md and spec/1.0.0.md in agentplugins/agent-plugins-spec, and from issue #41 in the same repository, all fetched on that date. Validate a manifest at /validator, see the ecosystem numbers on Agent Plugins statistics, or start a package with the build guide.