How Gnosem lists on the Official MCP Registry, PulseMCP, Smithery, Glama, and mcp.so simultaneously

The Model Context Protocol ecosystem grew a lot of directories fast. There's the Official MCP Registry, which went to preview in late 2025 with backing from Anthropic, GitHub, PulseMCP, and Microsoft. There's PulseMCP, the discovery site that predates the official registry. There's Smithery, which does install tooling and directory. There's Glama, which does its own metadata scraping and quality scoring. There's mcp.so, a Chinese-run aggregator with good SEO. Plus the two big awesome-mcp-servers GitHub lists (punkpeye and wong2).

You want to be on all of them, because your users find MCP servers by searching one of those places. But you don't want to submit seven times.

Good news: for most of them, you don't have to. The cascade works. Gnosem is listed on all five of the auto-ingesting directories from a single publish to the Official Registry — this post is the practical write-up of what actually cascades, what doesn't, and where publishers most often trip.

The single source of truth

The Official MCP Registry is designed to be the upstream. Its API at registry.modelcontextprotocol.io/v0/servers is what the downstream aggregators query on a scheduled ingest. Publish to the registry once and the aggregators pull your listing on their own timelines.

The publishing flow is a two-step, ~20-minute process:

1. Write a server.json manifest.
2. Publish it with mcp-publisher, authenticated by an Ed25519 signature over a DNS TXT record you control.

The full walkthrough with code is in Publishing to the Official MCP Registry. This post assumes you've done that step or are about to, and focuses on what happens next.

What cascades automatically

Once your listing is live on the official registry (which happens the moment mcp-publisher publish succeeds), the following downstream directories will ingest without further action:

PulseMCP

PulseMCP runs a daily ingest from the official registry. Gnosem's listing appeared on PulseMCP within about 24 hours of the official-registry publish. No submission form to fill out. If your registry manifest has a good description and a working URL, PulseMCP's listing looks identical without additional work.

Smithery

Smithery ingests from the official registry and also does its own scan of your MCP endpoint to fill out tool-list metadata. This is where Bearer-token-gated servers hit a wall: Smithery's scan hits your /mcp endpoint without an Authorization header, gets a 401, and falls back to whatever metadata was in the registry.

The workaround: serve a /.well-known/mcp/server-card.json alongside your gated MCP endpoint. This is a public endpoint returning the same server-card metadata that a successful MCP initialize would return. Smithery reads it and gets the full tool list without needing auth. Gnosem's card lives at gnosem.dev/.well-known/mcp/server-card.json.

Glama

Glama pulls from the official registry plus its own scans, and requires a public GitHub repository URL in the manifest's repository.url. If you don't have one, Glama's listing will exist but be much sparser (no README rendering, no license badge, no stars). Even a README-only repo helps.

Glama also runs its own quality scoring, so metadata like a clear description, an actual license file in the repo, and evidence of maintenance (recent commits) all move the score.

mcp.so

mcp.so ingests from the official registry on a slower cycle — Gnosem took about three days to appear. Nothing to configure; it just takes longer. mcp.so has strong SEO in some markets, so it's worth the wait even if the ingestion lag is annoying.

What doesn't cascade

Two categories don't auto-ingest and still require you to do the work:

The awesome-mcp-servers GitHub lists

Both punkpeye/awesome-mcp-servers and wong2/awesome-mcp-servers are curated by hand. Neither reads the official registry. If you want to be on those lists:

• punkpeye — open a pull request against the repo adding a single line in the appropriate category. Concise description, name-linked to your homepage. Review is usually a few days.
• wong2 — submit via the web form at mcpservers.org/submit. Turnaround similar.

Both lists are lower-priority than the auto-cascade sites in terms of discovery volume, but they're where enthusiast users browse and where you get some GitHub-organic traffic. Do them both once, then forget about them.

Vendor-specific directories

Anthropic, OpenAI, and other model vendors are starting to build their own MCP server marketplaces or featured lists. These are curated, invite-only, or require a partnership process. They're outside the registry cascade entirely. If you have a reason to be on Anthropic's featured list, that's a separate conversation with Anthropic. The cascade helps you get discovered enough that those conversations become feasible.

Why DNS-verified namespaces matter for the cascade

The Official Registry supports two kinds of namespaces: reverse-DNS namespaces (like dev.gnosem) that require DNS verification, and io.github.<user>/ namespaces that are auto-issued to any GitHub user.

Publishing under a DNS-verified namespace matters for the downstream cascade in one specific way: the aggregators treat DNS-verified listings as first-party. Glama, for instance, shows a "verified" badge for DNS-namespaced servers and de-prioritizes GitHub-namespaced ones in some search rankings. PulseMCP surfaces the domain of the server prominently, which reads as more legit when it matches your product's domain.

For anything you'd call a product (not a hobby server), DNS verification is worth the 15 extra minutes.

The failure modes we hit

Three sharp edges from actually running this cascade for Gnosem:

Description length. The registry caps description at 100 characters. If you write a 120-character description, validation rejects with 422. The downstream aggregators inherit the same description, so you have exactly 100 characters to communicate the value proposition. Ours: "Cross-vendor AI memory over MCP. One semantic store, readable and writeable from every MCP client." — 98 chars.

Bearer-gated endpoints trip Smithery. If your MCP server requires an Authorization header (which it should if it's a hosted per-user product), Smithery's scan will 401 and fall back to registry metadata. Publishing a public server-card at /.well-known/mcp/server-card.json is the fix. This is not documented in the MCP spec directly; it's a convention some scanners rely on.

Missing metadata index. Not a cascade failure, but adjacent: if you're using Cloudflare Vectorize and you want per-user filtering in the vector query, you have to create the metadata index at provisioning time. Without it, filter queries silently return empty. Discussed in Building an MCP Server on Cloudflare Workers. Mention it here because if your server responds to Smithery's scan by returning empty tool lists (because filtered lookups fail), your listing looks broken even though it's not.

What a good registry manifest looks like

Since every downstream directory inherits your registry manifest, it's worth writing carefully. Here's Gnosem's:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "dev.gnosem/gnosem",
  "title": "Gnosem",
  "description": "Cross-vendor AI memory over MCP. One semantic store, readable and writeable from every MCP client.",
  "version": "1.0.0",
  "repository": {
    "url": "https://github.com/gnosem/gnosem",
    "source": "github"
  },
  "websiteUrl": "https://gnosem.dev",
  "remotes": [
    {
      "type": "streamable-http",
      "url": "https://gnosem.dev/mcp"
    }
  ]
}

Every field earns its keep:

• name: reverse-DNS format, DNS-verified.
• title: display name. Simple.
• description: 98 characters, states the value proposition and the mechanism.
• repository.url: needed for Glama to render the README and license.
• websiteUrl: this is where downstream aggregators link. Should be your marketing landing page, not the MCP endpoint.
• remotes: streamable-http type is the modern one. Include the actual MCP endpoint URL.

Not shown but worth adding if applicable: packages (if you also distribute an npm-installable local variant), icon (some directories render it).

The lesson

The MCP ecosystem is early enough that the cascade infrastructure works surprisingly well. One publish, one afternoon, five directories over the following few days, no per-directory submission grind. This is not the historical norm for developer tooling ecosystems — usually every directory demands its own submission with slightly different metadata requirements and its own dashboard to log into. The MCP world has, so far, been much more federated. Publishers benefit; users benefit; the aggregators benefit because they get high-quality first-party data instead of scraping the web.

If you're building an MCP server, do the registry publish. It really is a 20-minute task and it's the highest leverage marketing action available. Then submit to the two awesome-mcp-servers lists as a manual afterthought. That's the whole distribution loop.

See Publishing to the Official MCP Registry for the exact commands, and the Gnosem landing page for what a published MCP product looks like from the user side.