## TL;DR

Each MCP registry has its own requirements: namespace or org setup, a server manifest, verification of ownership, and listing metadata. Read each registry's submission docs before starting, get the manifest right once, then adapt per registry. Test the server against the protocol before submitting anywhere; registries reject broken implementations.

```text
submitting to MCP registries: per-registry requirements
```

## Use this when

- You have a working MCP server to distribute
- Planning registry submissions as a batch
- A registry rejected your submission and you need the checklist

## Not for this skill when

- The server does not correctly implement MCP yet (test first)
- You are submitting a plain API, not an MCP server
- The registry is unmaintained (check recent listings first)

## Steps

1. Verify the server implements the protocol cleanly. Run it against a real MCP client: initialize, list tools, call a tool. Expected: all three work without errors before any submission.

2. Read each target registry's submission docs. Note the namespace rules, manifest format, verification method, and review process. Expected: a per-registry requirement list.

```
per-registry notes:
  registry: [name]
  namespace: [how names are claimed]
  manifest: [format and required fields]
  verification: [DNS / file / account]
  review: [auto / manual, expected wait]
```

3. Prepare the manifest once. Name, description, version, transport, tool list, auth requirements, repo and docs links. Expected: one canonical manifest to adapt per registry.

4. Complete verification per registry. Usually proving control of a domain or repo; do exactly what the docs say. Expected: verification passes on the first try.

5. Submit and track like any directory submission: date, status, listing URL when live. Expected: the registry batch joins your normal tracking sheet.

## Variant phrasings

### how to list an MCP server in registries

Verify the implementation, read each registry's docs, prepare one manifest, verify ownership, submit.

### MCP registry submission checklist

Working server, per-registry requirements, canonical manifest, verification, tracking.

### MCP server discoverability via registries

Registries are one channel; keep the manifest and docs URLs stable everywhere.

## Why it happens

Registries are how agents and operators discover MCP servers, but there is no single standard submission flow yet. Each registry grew its own process, so the work is reading and adapting, not filling one universal form.

## Edge cases / pitfalls

- Namespace squatting disputes happen; claim your namespace early on registries you care about.
- Version your manifest; registries cache listings and stale versions confuse operators.
- Some registries require ongoing liveness; a dead server gets delisted.
- Keep the submission docs links; registries change their processes without notice.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sdc09JYZsc6kiZvLPl2Nag