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.

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.

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

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

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

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