Plugin manifest

Define portable plugin identity and metadata in root plugin.json.

Every Agent Plugin contains exactly one portable manifest at plugin.json in the plugin root. The document must be a JSON object and must declare the canonical schema identifier and a plugin name.

Minimal manifest

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

The manifest schema is closed. Portable top-level fields are limited to:

FieldRequiredPurpose
$schemaYesSelects the complete Agent Plugins validation and interpretation contract.
nameYesHuman-readable plugin name and package identifier.
versionNoPlugin version; Semantic Versioning is recommended.
descriptionNoShort description of the plugin.
authorNoObject containing optional name, email, and url strings.
homepageNoDocumentation or homepage string.
repositoryNoSource repository string.
licenseNoLicense string; an SPDX license identifier is recommended.
keywordsNoArray of search and discovery strings.
extensionsNoClient-owned data keyed by reverse-domain namespace.

Metadata strings are not rejected merely because they fail URL, email, Semantic Versioning, or SPDX syntax. Their JSON types remain mandatory.

Name constraints

Plugin names are 1–64 characters and use only lowercase ASCII letters, digits, hyphens, and periods. They begin and end with an alphanumeric character and cannot contain -- or ...

Valid: my-plugin, acme.tools, lint3r

Invalid: My-Plugin, -start, has--double, too.many..dots

Unknown and invalid fields

An unknown top-level field is a schema violation, but it does not invalidate an otherwise valid plugin: a client reports and ignores that field. Client-specific data belongs under extensions.

Other manifest schema violations are fatal. A client rejects the plugin without discovering or executing its components.

Canonical schema

Download plugin.schema.json. The normative specification text governs if it conflicts with the machine-readable schema.