## TL;DR
Every MCP registry asks for roughly the same things (name, description, tools list, repo link) but they differ on verification, review speed, and how updates work. The fix for a stalled submission is almost always a missing verification step or an incomplete tools manifest, not the server code. Compare the big three on five dimensions before you submit, and you will pick the right one on the first try.

```text
MCP registry requirements compared across registries
```

## Use this when
- You are deciding which registries to submit an MCP server to
- A submission has been sitting in review with no feedback
- A listing got rejected and the reason was vague
- You want one submission package that works everywhere
- You are comparing distribution reach of MCP vs other channels

## Not for this skill when
- You have not built the server yet (see testing and building guides first)
- The question is about the MCP protocol spec itself, not registries
- You are choosing between MCP, API, and CLI as distribution (different skill)
- You need legal advice on licensing for a registry listing

## Steps
1. Shortlist the registries that matter for your server. The ones with real agent traffic are the official MCP registry reference, mcp.so, and Smithery, plus a long tail of curated lists. Write down which of the three you will target first.
   ```text
   target registries:
   [ ] official reference registry
   [ ] mcp.so
   [ ] Smithery
   ```
   Expected output: a named shortlist, not "everywhere". Success check: you can say why each one is on the list.

2. Pull the live submission docs for each registry and normalize them into one table. Registries change their rules; the docs page is the source of truth, not a blog post from six months ago. Compare these five columns: required metadata, identity verification, review model, update flow, analytics.
   ```text
   | dimension        | registry A | registry B | registry C |
   | required fields  |            |            |            |
   | verification     |            |            |            |
   | review SLA       |            |            |            |
   | updates          |            |            |            |
   | stats provided   |            |            |            |
   ```
   Expected output: a filled comparison table. Success check: every cell has a citation to a docs URL or a dated note.

3. Check the identity and namespace rules before anything else. Most registries require you to prove you own the repo or domain the server points to, and some reserve official-looking namespaces. A mismatch here is the most common silent rejection.
   ```text
   [ ] repo ownership proven (org membership or signed commit)
   [ ] namespace matches your org or project name
   [ ] no trademarked names you do not own
   ```
   Expected output: all three boxes checked. Success check: you know exactly which account must submit.

4. Validate your tools manifest against the strictest registry on the list. Each tool needs a name, a plain-language description, and a declared input schema. Descriptions written for humans ("does stuff") get bounced; descriptions written for agents ("lists open pull requests for a repo, takes owner and repo") pass everywhere.
   ```text
   [ ] every tool has a description a new agent could act on
   [ ] input schemas declare required vs optional fields
   [ ] no tool duplicates another registry listing under a new name
   ```
   Expected output: manifest passes the strictest registry's linter. Success check: zero warnings, not just zero errors.

5. Submit to one registry first and watch the review clock. Note the time from submit to listed, and what questions the reviewer asked. That log becomes your template for the next two submissions, and reviewer questions are free QA on your listing copy.
   ```text
   submitted: [date]  listed: [date]  reviewer questions: [notes]
   ```
   Expected output: a dated submission log. Success check: you can predict the second registry's questions before they arrive.

## Variant phrasings
### MCP registry submission requirements
Same comparison, framed as a checklist instead of a table. Some builders search for the requirements doc, not the comparison; the content is the same five dimensions.

### Which MCP registry should I submit to
Decision-first phrasing. Answer with the shortlist logic from step 1: reach, review speed, and whether your server fits the registry's curation bar.

### MCP server listing rejected, what to check
Troubleshooting phrasing. Start at step 3 (identity/namespace), then step 4 (manifest quality). Those two cover most rejections.

### Smithery vs mcp.so vs official registry
Head-to-head phrasing. Use the table from step 2 and keep it dated, since the differences shift every few months.

## Why it happens
Registries are trust infrastructure. An agent that installs a malicious or broken MCP server blames the registry, so every registry gates on identity and manifest quality, just with different strictness and different review capacity. The variance you see is each registry trading off growth (list everything fast) against trust (review everything carefully).

## Edge cases / pitfalls
- Requirements drift. Re-check the docs within a week of submitting; a table from last quarter will mislead you.
- Some registries auto-import from GitHub and create stale duplicates. Claim or report duplicates of your own server so agents do not install the abandoned copy.
- A listing that passes review can still rot. If your server changes tools, update every registry listing the same week or agents will call tools that no longer exist.
- Namespace squatting happens. If someone lists your project name first, most registries have a dispute process, but it is slow; submitting early is the real defense.

## Provenance

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