Registry and marketplace

Every control-plane installation owns its registry. Nothing is fetched from, or sent to, vendor infrastructure unless a platform administrator imports from a public registry. On the managed cloud we curate the marketplace; the architecture is identical.

Packages and namespaces

A package is identified by @namespace/name and holds immutable versions.

• Each organization and each person gets a namespace on first use, from the organization slug or the email name.
• @platform belongs to platform administrators.
• A bare name (react-review) still works when installing: the organization's own package is tried first, then the platform's, then the person's.

Owners and visibility

Publishing

The owner asks for a package to be published: listed (shown in the marketplace) or unlisted (installable by reference).

1. Automated checks run first. They refuse secrets in manifests, instructions that tell agents to ignore their rules, send credentials away or hide actions, curl … | sh, and plugins without code. They warn about high-risk permissions, permissions added since the previous version, and thin descriptions.
2. A platform administrator approves — granting COMMUNITY, VERIFIED or OFFICIAL trust — or rejects with notes.

New versions of a published package must pass the automated checks; its trust carries over.

Curation

Platform administrators mark public packages curated, with an optional rank. Every listing shows curated packages first. The dashboard's marketplace shows curated packages only; when none match the search it shows all packages, with a note to check trust and permissions.

Versions

Installations pin an exact version and its digest, and keep a range (default ^<version>).

• Upgrade moves to the newest version in the range. If the new version adds permissions, a non-administrator's upgrade goes back to pending approval.
• Publishers can deprecate or yank versions. Yanked versions cannot be installed and are not delivered to agents.

Mirroring the MCP Registry

Platform administrators can mirror the official MCP Registry (or a compatible one) from Server → Marketplace, or with POST /api/v1/admin/registry/import/mcp-registry.

• Only metadata is stored; servers run from their npm, PyPI or OCI package or remote URL.
• Mirrored packages are UNVERIFIED and never replace a package or namespace claimed on this server.
• Environment variables a server declares become installation configuration. Secret ones are not delivered to workers.

Categories, technologies and search

Every package is categorized automatically from its name, description, readme, instructions, triggers and configuration: up to three of 21 fixed categories, and the technologies it recognizes from a vocabulary of about 100. Publishers may choose up to three categories as a hint; platform administrators can pin them.

Search takes category and technology filters. It uses MongoDB text search by default; with REGISTRY_SEARCH=atlas on MongoDB Atlas, create an Atlas Search index named capability_packages on the capabilitypackages collection for fuzzy, relevance-ranked search.

See also Stacks and Suggestions.

Public catalog

With PUBLIC_CATALOG=true (default on only with DEPLOYMENT_MODE=cloud), these answer without sign-in, return public packages only and are cacheable:

Thin mirrored entries are marked not indexable and left out of the sitemap.