I got my MCP server into the official MCP Registry and assumed distribution was handled. Eight days later I searched for it in every browsable MCP directory I could find, and got nothing. The registry is a database that other tools may read. The places people actually browse each want their own submission, and none of them came looking.
So I did them one at a time. Three traps were worth the trip.
Smithery publishes from a CLI. You claim a namespace, then publish your URL, and their scanner connects to your live endpoint and enumerates your tools. Because my server requires sign-in, the scan stopped and printed a one-time authorization link. I had started the publish in a background shell, so that process was long gone by the time I clicked it. The documented recovery, --resume, answered 400 {"error":"Deployment is not in AUTH_REQUIRED state"}. The real fix was mundane: publish again. Smithery had kept the authorization, and the new scan walked straight through — [scan] Capabilities found: 6 tools, 25 resources.
My listing had no description. I assumed the directory would read the server's own metadata, so I added MCP's instructions field to my initialize response and re-published. It changed nothing. The blurb and the icon are set by hand in their dashboard. The instructions work wasn't wasted — real clients do use it to brief their agent — it just isn't where a directory gets its description.
Their registry API lied to me. While debugging the missing description I kept polling registry.smithery.ai, which returned an entry with no tools and no URL, while the actual web page was complete and correct the entire time. I burned twenty minutes on a phantom because I trusted the API over the page a human sees.
mcp.so was the easy one: no API, no form — the submission is a GitHub issue on their repo.
Two days later I had to correct myself. I went to submit to the last two directories and found there was nothing to submit. One had already listed the server on its own — name, description, endpoint, auth, all pulled from the official registry, dated that same day. The other had paused submissions entirely, with a note saying to publish to the official registry because they pick it up automatically when they reopen.
So "each one wants its own submission" was half wrong, and the half that was right has a pattern underneath it. The directories that made me submit by hand are the ones that connect to your live endpoint; the ones that read the registry need nothing from you, because the registry already holds what they display. Before writing a submission, check whether the directory is a scanner or a mirror. For a mirror you are already done.
One tell that it is a mirror: its listing shows your description and URL but no tools. It never connected — and if your endpoint is behind sign-in, as mine is, it cannot.
The finished listing scored 98/100. The missing two points are for tool names forming a dotted tree, like stories.search. I'm not taking them. OpenAI's function-name pattern is ^[a-zA-Z0-9_-]{1,64}$ — dots are rejected outright, and Anthropic's is the same shape — so scoring those two points would break the exact clients the listing exists to reach. Sometimes the scorecard is wrong, and the useful skill is knowing which criterion to fail on purpose.
Reproduce this
Prerequisites: a remote MCP server already deployed at a public HTTPS URL speaking Streamable HTTP; Node 18+ (for npx); a GitHub account. Publishing to the official MCP Registry first is recommended but not required — that is a separate story, Getting into the MCP Registry.
Your agent will need from you: your server's public MCP URL; the org/name you want to own; a one-line description and a square icon under 1 MB; and one click in a browser when an authorization link appears.
Steps:
- Log in to Smithery with the official CLI,
@smithery/cli(tested at 4.11.1):npx -y @smithery/cli@latest auth loginIn a non-interactive shell it prints JSON containing anauth_urlinstead of opening a browser — open that URL yourself. - Claim your namespace, then confirm it is the active one:
npx -y @smithery/cli@latest namespace create <org>npx -y @smithery/cli@latest namespace list - Publish, in the foreground — this is trap one:
npx -y @smithery/cli@latest mcp publish <https://your-server/mcp> -n <org>/<name>Note thedeploymentIdandlogFilepath it prints. - Watch that
logFile. If your endpoint requires authentication it will stop at[scan] Authentication required. Please authorize at: <link>. Open the link and authorize. - If the CLI process already exited before you authorized, do not reach for
--resume; it returns400 Deployment is not in AUTH_REQUIRED state. Run the exact samemcp publishcommand again — the authorization is stored against the server, so the fresh release scans through without prompting. - Set the description and the icon by hand in the Smithery dashboard for your server. The
instructionsfield of your MCPinitializeresponse is not used for this, so do not spend a deploy on it expecting the listing to change. - Submit to mcp.so by opening a GitHub issue on chatmcp/mcpso containing: name, remote endpoint, website, GitHub repo, official registry id, category, author, a contact URL, what it does, the tool list, and the install command. There is no API and no form.
- Read the directory's quality score, but check any naming criterion against the tool-name rules of the clients you care about before acting on it.
Verify:
- Open
https://smithery.ai/servers/<org>/<name>in a browser and confirm your tool list, the connect URL and your icon all render. Do not verify viaregistry.smithery.ai— it can serve an empty entry for a listing that is fully live (trap three). - Confirm the scan log contains
[scan] Capabilities found: N tools, M resources, with N and M matching what your server actually exposes. - Confirm your mcp.so issue exists and has an issue number.
- A week later, search your server's name in each directory. That search result — not the submission — is the thing you were actually trying to buy.