---
title: "Agent Plugins Ships No Official Validator"
description: "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 wor"
canonical: https://agentpluginsdirectory.com/blog/no-official-validator
last-updated: 2026-09-21
---

# 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 `test` manifest 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.

647 of the 4,840 conformant manifests sit at test-fixture paths inside 74 repositories. They are conformance test cases, not installable plugins, which is why they are excluded from the verified count of 2,765. In the 2026-08-08 census the five repositories supplying 106 of the 127 fixtures were all linters or conformance harnesses: `HiAi-gg/agent-plugins-doctor`, `kuralle/kuralle-agents`, `stbenjam/skillsaw`, `Toasterson/agent-plugin-rs` and `Toasterson/agent-plugin-ts`. Fixture manifests grew 115% between 2026-08-07 and 2026-08-08 against 90% for plugins, so validator projects are appearing at least as fast as the packages they check.

| 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 [plugin.json validator](/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.

**Plugin counts verified on 2026-08-08** 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 2026-08-07. Validate a manifest at the [plugin.json validator](/validator), see the ecosystem numbers on [Agent Plugins statistics](/stats), or start a package with the [guide to building an Agent Plugin](/build).