The Model Context Protocol ecosystem has grown fast, and with it a handful of registries that have become the front door for discovery. If you have built an MCP server and nobody can find it, you have built half a product. This week I took HALO — my local, autonomous security agent — through the full listing process across every major registry. Here is the practical walkthrough, in the order that actually works.
Step 0: Make it a real MCP server first
This is the step most people skip, and it is the one that gates everything else. It is not enough to call something an MCP server. The registries inspect your repository, launch the server, and enumerate its tools. If it does not speak the protocol, it fails silently and you never understand why.
The cleanest architecture separates transport from execution. I moved my tool logic into a single transport-agnostic engine, then put two thin layers on top: a spec-compliant MCP server that speaks JSON-RPC over stdio using the official SDK, and the existing local interface my agent already used. Defining the tool schemas once, in one registry, means both layers stay in sync and there is no drift.
I also added a server.json manifest at the repository root. Several registries read it directly, and it signals that you know what the ecosystem expects.
The test that matters: a real MCP client should be able to initialize, call tools/list, and get back your full arsenal with valid input schemas. If that round-trip works, you are ready to submit. If it does not, no registry will save you.
Step 1: Glama
Glama indexes MCP servers directly from GitHub and assigns each a quality score. Once your repository is a genuine server, sign in, submit the repo, and let its inspector do the work. The payoff is a live score badge you can embed anywhere — and, more importantly, that badge is what several other directories validate against. Glama is the keystone; get it green first.
Step 2: awesome-mcp-servers (punkpeye)
The largest community list. Contribution is a straightforward pull request: find the correct category, match the existing entry format exactly — repository link, score badge, language and scope emoji, then a one-line description — and add your line. An automated check validates the submission against Glama. Because I had already earned a Glama score, that check passed cleanly, and the PR dropped into the merge queue.
Two details save time: match the neighbours' formatting precisely, and do not fight the review automation. A skipped "welcome" workflow is not a failure; the submission check is the one that counts.
Step 3: awesome-mcp-servers (TensorBlock)
A different list with a different process. Instead of hand-editing a giant README, TensorBlock offers an "Add MCP server" issue form and drafts the pull request for you from the fields you provide. Lower friction, fewer formatting mistakes. Pick your category, describe the server plainly, and submit.
Step 4: mcpservers.org
A hosted directory with a simple submission form: name, description, link, category, contact email. Free listings are the default; ignore the paid "premium" upsell unless speed genuinely matters to you. Choose the most honest category available — a precise "Other" beats a wrong label that buries you under the wrong search.
What I would tell my past self
- The engineering comes before the marketing. A registry submission is only as good as the server behind it.
- Glama first. Its score is the currency the other lists trade on.
- Match each destination's format on its own terms; they are not interchangeable.
- Be accurate in your metadata. Miscategorising to chase visibility costs you the audience you actually want.
None of these steps is hard on its own. The discipline is doing them in the right order, and refusing to submit anything until the thing you are submitting is real. Do that, and a project goes from invisible to discoverable in an afternoon.
Top comments (0)