A reason for every place.

Two collections, clearly distinguished

The server collection contains projects built by the owner, including alpha and experimental work. The curated rack contains tools from other makers used in the owner's workflows. Inclusion is not independent certification or a security audit.

What a candidate needs

• A clear job it helps an agent or its operator do.
• An identifiable maker and a direct source or documentation link.
• Setup instructions and understandable access requirements.
• Limitations that can be described honestly.
• A reason to use it that goes beyond being another MCP server.

Evidence before badges

Package availability, registry membership and maturity labels describe different things. A registry listing is not a safety guarantee. Version information is a recorded snapshot; consult the package source for current releases. A build timestamp on the catalog does not mean every server was re-tested at that time.

What the labels mean

• Experimental: exploring a use case; the supported scope may change.
• Alpha: working source with incomplete installation, operational or release evidence.
• Preview: an early companion tool or limited-access product with stated availability.
• Beta: a bounded workflow is available for testing; supported scope and limitations are documented.
• Stable: the declared core has a versioned contract, repeatable installation and recovery checks, and recorded operational evidence.

Existing labels are maintainer-reported snapshots. A dated metadata review checks the listing against source and release records. A runtime review records actual checks of a named version and environment. Neither means an independent security audit.

Moving to the next stage

For a new beta, record a clean versioned installation, passing release checks, an end-to-end workflow in at least 2 supported clients, and the outcome of applicable security findings. State permissions, data handling and known failure modes.

For stable, also document the supported contract, upgrade and support policy, recovery checks and resolution of critical or high-severity defects in that scope. The default evidence window is 30 days, with 2 independent operator reports and 3 representative workflows. Product-specific exceptions need a written rationale in the receipt. Optional experimental features can stay outside the stable core.

Every promotion needs a promotion receipt: version and commit, artifact checksum, test and CI links, client and platform versions, workflow outcomes, limitations, reviewer and review date. When those facts change, narrow or revise the label.

Suggestions and invitations

Makers can suggest a server for review. A suggestion does not guarantee a listing, a response time or a favourable recommendation. Invited makers are held to the same standard.

Commercial listings

Paid listings are not currently offered. If commercial placements are introduced, they will be labelled and separated from editorial selection. Payment will not buy a safety claim or a recommendation.

Corrections and removal

A listing can be corrected, narrowed or removed when its source, maintenance or fit changes. Use the repository to report an outdated link or factual error, with a primary source where possible.

Suggest a server or correction →