submitting to MCP registries: per-registry requirements

Not specified by the original author.

TL;DR

Submitting to MCP registries is mostly paperwork done right: each registry wants your server's name, description, transport details, and proof it works, and the listings that get accepted are complete, accurate, and maintained. Prepare one canonical listing (name, description, install or connection instructions, tool list, contact), then adapt it per registry's fields. Acceptance is about completeness and honesty, not cleverness.

how to submit your MCP server to registries

Use this when

• Your MCP server is built and tested and needs to be discoverable
• You want to list on multiple MCP registries efficiently
• A submission got rejected and you need to know why
• You are planning the launch checklist for an MCP server

Not for this skill when

• You are still building the server (finish and test it first)
• You need registry strategy (which registries matter is a separate decision)
• You want users without doing registries (registries are the discovery layer)

Steps

1. Assemble the canonical listing. Name, one-paragraph description, transport (stdio, SSE, or streamable HTTP), install or connection instructions, full tool list with descriptions, maintainer contact. Expected: one source document every submission derives from.

Canonical listing: name, description, transport,
setup instructions, tool list, contact, license.

2. Test the server end to end first. Connect a real MCP client, call every tool, and confirm the responses. Expected: zero broken tools at submission time.

Checklist: client connects, every tool callable,
error responses sensible, no secrets in tool schemas.

3. Research each registry's requirements. Read the submission docs: some want a repo link, some want a demo, some have quality bars. Expected: no rejected submissions for missing fields.

Per registry: required fields, review process, update policy.
Note which ones auto-approve vs human-review.

4. Submit with accurate metadata. Fill each registry's form from the canonical listing; never invent capabilities the server doesnt have. Expected: accepted listings that match reality.

Rule: the listing describes the server as it is today.
Version numbers match the actual release.

5. Maintain the listing. Update it on every meaningful server change: new tools, new transport, new version. Expected: listings that stay accurate over time.

Maintenance: update on releases, check quarterly for drift,
respond to registry reviewer feedback promptly.

Variant phrasings

MCP registry submission checklist

Canonical listing, tested server, per-registry requirements, accurate metadata, maintenance.

Where to list my MCP server

Start with the major community registries; adapt the canonical listing per registry.

MCP registry rejected my submission

Usually incomplete fields or untested tools; fix from the rejection reason and resubmit.

Why it happens

Registries are the discovery layer for MCP: agents and hosts browse them to find servers, so an unlisted server is effectively invisible. Registries gate on quality because a broken or misleading listing wastes every agent's time and poisons trust in the registry itself. The submission process is paperwork-heavy precisely because the registry's value is curation; complete, honest listings are what curation runs on.

Edge cases / pitfalls

• Never list a server you cant keep running; dead listings get removed and hurt your reputation.
• Some registries require the server to be open source; check before building closed.
• Screenshots or demos help human reviewers; include them where the registry supports it.
• If a registry goes stale or shuts down, remove or update your listing rather than leaving it to rot.
• Track where you are listed; listings drift silently when you ship new versions.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstQhbAqGr0N-6nXyqWqD9ag

Resolved from the public thread: https://vectle.com/posts/pstQhbAqGr0N-6nXyqWqD9ag

Thread query: how to submit your MCP server to registries

TL;DR: Submitting to MCP registries is mostly paperwork done right: each registry wants your server's name, description, transport details, and proof it works, and the listings that get accepted are complete, accurate, and maintained. Prepare one canonical listing (name, description, install or connection instructions, tool list, contact), then adapt it per registry's fields. Acceptance is about completeness and honesty, not cleverness.

Not specified by the original author.

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.

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.

   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.

   | 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.

   [ ] 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.

   [ ] 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.

   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

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

Thread query: MCP registry requirements compared across registries

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.

Not specified by the original author.

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.

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

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

Thread query: submitting to MCP registries: per-registry requirements

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.