How to list your MCP server on the MCP Registry

Getting your MCP server “listed” in the registries isn’t one job. It’s two that people keep blending together. There’s the MCP Registry, the community-run feed a growing number of AI clients read to discover servers, where you publish a record of your server and prove you own its name. And there are discovery directories like Smithery, Glama, and PulseMCP, which crawl the ecosystem, rank what they find, and let you claim what’s yours. The registry is the source. The directories are the storefronts that read from it. Do the registry first, because much of the rest is downstream of it.

Here’s the part that throws people coming from the Anthropic or OpenAI route. None of these directories review your server the way a vendor does. There’s no queue, no reviewer, no rejection email. You publish, or you get crawled, and you show up.

That sounds easier, and the mechanics are. The catch is that anyone can publish anything, so the trust signal moves from “a reviewer accepted it” to “the owner verified it and the record is clean.” That’s the bar you’re actually clearing here.

The registry is the feed, the directories are the storefronts

Start with what each thing is, because the names blur together and the jobs don’t.

The MCP Registry is a single community-run service. Its own docs put it plainly: it “provides MCP clients with a list of MCP servers, like an app store for MCP servers.” No single vendor owns it. It’s a shared catalog the ecosystem maintains, and a growing set of clients and tools read it to answer one question: what servers exist, and where do I reach them? That’s why it matters more than its low profile suggests. A record here can propagate to places you never submitted to.

The directories are a different animal. Smithery, Glama, and PulseMCP are search-and-discovery sites. They crawl GitHub and the registry, index whatever they find, and rank it for people browsing for a tool. They’re where a human goes to shop. They’re also where your server can already exist as an unclaimed crawl result with a description you didn’t write, which is a messy little problem worth fixing.

So the order isn’t arbitrary. Publish to the registry, and the directories often pick it up. Skip the registry and chase directories one by one, and you’re doing manual work the feed would have done for you. This is the same build-once-reuse-everywhere logic that runs through getting into Claude’s Connectors Directory, just with publishing instead of review.

What publishing to the registry actually takes

The registry doesn’t grade your server. It checks that you are who you say you are, and that your record is well-formed. Two requirements carry the weight.

First, the namespace. Servers are named in reverse-DNS form, and you have to prove you own the name. The registry’s own examples spell it out: to publish io.github.yourname/your-server you log in to GitHub as that user, and to publish under a custom domain you “prove ownership of” it “via DNS or HTTP challenge.” A server published under com.tallyfy/mcp-server means somebody proved they control tallyfy.com, not just a GitHub handle. That ownership proof is the whole trust mechanism. It’s why a registry record means more than a random repo.

Second, the record itself. You publish a server.json using the registry’s mcp-publisher command-line tool. The file is small and strict, and getting its fields right is where first-timers stall. Here’s the live record for a server we run, pulled straight from the public registry API:

Read what’s in there, because it’s the shape every record takes. A schema link that validates the file. A reverse-DNS name. A human title and a short description. A repository pointing at the public source, a version, and a websiteUrl for the docs. And the field that does the real work, remotes, which tells a client the transport (streamable-http) and the URL to reach the server at.

Notice what isn’t there: no OAuth scopes, no tool list, no annotations. The registry record is a pointer. The actual handshake, auth, and tool discovery happen when a client connects to that remote and the server answers. If you want the protocol mechanics behind that exchange, our explainer on how MCP servers work covers the architecture.

A practical note that saves a resubmit. The registry tracks versions and an isLatest flag, so publishing an update isn’t a delete-and-replace; it’s a new version that supersedes the old one. Get the namespace and the transport right the first time and the rest is editing a small JSON file.

This is also the point where a defined process matters more than the listing. A listed server hands an agent a set of tools it can call, but the listing says nothing about the order to call them in or when to stop and ask a person. That sequencing lives in the workflow, not the model, which is the thread running through how AI changes the way work gets done.

Getting picked up by Smithery, Glama, and PulseMCP

The directories are the easier half, with one trap. Turns out they find you whether you ask or not, so your job is less “submit” and more “claim and clean up.”

Smithery is built around connecting agents to tools, and it takes a publish step: its docs describe “publish your MCP server to Smithery for distribution and observability.” Its command-line tool runs smithery mcp publish <your-url> -n yourorg/your-server, and its own CLI bills the catalog as 100,000-plus tools and skills. A server we operate sits there under the name tallyfy-inc/mcp-server, which is the kind of clean, owned listing you want rather than an auto-generated stub.

Glama leans harder on scale and verification. In mid-2026 its directory tracked 36,950 servers, and it splits them into tiers worth understanding: an “Official” set of publisher-verified entries and a larger “Claimed” set where an author has verified ownership. The rest are just crawled. Getting your server out of the anonymous-crawl pile and into the claimed tier is the upgrade that’s available to anyone willing to do it. PulseMCP rounds out the trio as a discovery and search site that indexes servers for people comparing options.

Across all three, the move is the same. Find your server, claim it, fix the description and links so they read like you wrote them, and let the verified-owner signal do its quiet work. None of this is hard. It just doesn’t happen on its own.

Where should you list first?

The registry, then the directories, then nothing else until those are clean. That’s the order, because the first one feeds the rest.

The registry is the one place that propagates. Publish a correct server.json there and the directories that crawl it can pick up an accurate record instead of guessing from your repo. Reverse the order and you’re cobbling together the same listing in three places. So spend your first hour on the namespace proof and the server.json, get the remotes transport right, and publish. Then go claim Smithery, Glama, and PulseMCP, in whatever order, since claiming is a no-brainer once the upstream record is good.

One thing the directories don’t replace is a server worth listing. A clean record pointing at a flaky endpoint helps no one. The work that makes a server worth finding is the same work the review-based surfaces demand anyway, which is why a server built to clear a ChatGPT app submission drops into these directories without a second thought. If you want to see how a server gets scoped so an agent can act without going off the rails, how Tallyfy keeps AI inside a defined process walks through the guardrails, and how Tallyfy’s MCP server is put together shows the build behind the listing.

Begin with the registry record: publish a correct server.json under a name you’ve proven you own, then claim the directory listings that already exist. Get the registry record right and the rest of the ecosystem starts reading from it. For the wider picture of how this fits alongside the vendor surfaces, the full map of where to list an MCP server lays out all of them side by side.