Skip to content
ECZ-IDPlugin
Verify an ECZ-ID

Distribution

One plugin, every marketplace

The same plugin is listed in several marketplaces, often under several publisher accounts, sometimes with different names. One ECZ-ID ties those listings to one identity — and each listing becomes a binding against it rather than a second plugin.

The subject

The plugin is the subject, not the listing

One Plugin Passport is one logical plugin, extension, action or store app your organisation publishes.

What is one identity

One logical plugin, extension, action or store app that your organisation publishes. It keeps the same ECZ-ID whatever it is called in a particular store, and whichever account publishes it there.

What is never a second identity

Releases, versions and individual store listings of that plugin are not separate Passports. A release is history. An install is an event. An execution is neither.

Bindings

What a listing binding records, and what it does not

The Passport identifies the plugin. A binding records a public place it already appears. Adding a binding never creates a second identity.

  • A marketplace or store listing

    The entry as it appears in a particular catalogue, recorded with where it was learned and when.

  • The source repository

    The repository the plugin is built from, as host, owner and repository name — never a branch and never a commit.

  • A published manifest

    The manifest URL you publish for the plugin, so a reader can reach the declaration the listing was built from.

  • A published package

    The ecosystem and name of the package that distributes it, without a version: the version is history, not identity.

A binding records that a relationship has been declared, with the date it was learned. It does not mean the marketplace agrees, it does not mean the listing is current, and it grants nothing.

Where the identifier goes

The record points back at itself

Publishing the identifier is what makes the identity useful: a reader who finds the plugin in a store can reach the record without being told where to look.

The canonical place for a plugin is its own manifest — the declaration the plugin already ships. An ECZ-ID and a link back to the Resolver record sit alongside the fields that are already there, and travel with the plugin into every catalogue that reads it.

Nothing about this changes the plugin’s behaviour. The identifier is metadata; it is not in the execution path, and it is not a runtime dependency.

The technical detail — the exact field names for each manifest format, and the schemas behind them — belongs to the Developer Gateway, which keeps them current. Open the Developer Gateway (opens in a new tab)

Adjacent

A plugin is not the thing it extends

Plugins sit between subjects that each have their own identity and their own operator. Keeping them apart is what makes any of it readable.

A plugin that extends an agent is a different subject from the agent. A plugin that bundles or connects to an MCP server is a different subject from the server. A plugin that calls an API is a different subject from the API, and the API keeps one identity across every plugin that uses it.

The identities that surround a Plugin Passport