We list a small marketing-data MCP server on six directories, and we check all of them near-daily (17 of the first 21 days — we log the gaps too). Not because it's exciting — because the only way to know what a listing is worth is to watch it. Three weeks in, here's the log.
The six
| Directory | How we check | Status after 3 weeks |
|---|---|---|
| Glama | curl the listing page, read uptime | Listed, healthy |
| Smithery | registry API + web page | Listed in registry; web page moved |
| MCPize | curl | Listed, stable |
| ModelScope | curl | Listed, stable |
| mcp-marketplace | curl | Listed, stable |
| Official Registry (npm-style) | registry API | Not found — possibly delisted |
Everything above is checkable with plain curl. No logins, no dashboards. That matters later.
What actually moved
Uptime, slowly. Glama publishes a rolling uptime score for listed servers. Ours started at 46.5% (inherited cold-start history) and has climbed through a dozen-plus readings since: … 61.5 → 62.3 → 64.6 → 65.2 → 65.5. Nothing we did was clever — the server just stayed up and the window rolled. But it compounds: health scores affect how directories sort you against the server next door.
Everything else: flat. Five stable listings, one possible delisting, zero visible discovery events we can attribute. Listings existing is not the same as listings working.
Two traps worth knowing about
Trap 1: a redesign looks like a delisting. One day our Smithery web page returned 404. Every URL variant, dead. The obvious conclusion — "we've been removed" — was wrong: the site redesigned its public pages, and the old paths simply vanished. The registry API still returned our full listing metadata. Same thing happened with Glama, which migrated server pages to a new "connectors" structure; the old URL 404s while the listing lives.
Trap 2: trusting one channel. Both traps were only diagnosable because we had two channels — the human web page and the machine API. If we'd only watched the page, we'd have filed two false delisting reports. Rule we now follow: a directory "disappearance" gets confirmed against its registry or API before it's believed.
The 30-second check
Six curls — five 200s and one expected not-found — plus one percentage value, logged in one line. The lesson isn't the tooling — it's that listing maintenance is boring, continuous, and the only source of truth about whether anyone's infrastructure moved under you. Weekly checks would have caught both redesigns days late; the uptime series would have gaps.
What we're watching for next
- Whether the official Registry entry comes back or stays gone
- Whether Glama's uptime plateau means anything (does ~70% change discovery?)
- The honest open question: we have listings and health, not users. When discovery does happen, the daily log is how we'll know what it came through.
Data notes: near-daily checks Oct 15 – Nov 4, 2026 (17 of 21 days), for one marketing-data MCP server listed on six directories. Uptime series read from the Glama listing page. Directory sizes for context (from published comparisons): Glama listed 111,635 servers as of Oct 28, 2026; Smithery linked to 27,365+.
Top comments (1)
"Listings and health, not users" matches what we saw at Auten (I'm on the team): GitHub showed 131 clones but 4 page views in 14 days after our listings, so nearly all of it was registry bots. What would you count as the first real discovery event: a referrer on your site, or an install that actually runs?
One trap like your redesign one: GitHub's MCP registry mirror silently ignored the search param on its older /v0/ path and just returned the first page, so it looked like we were missing. The /v0.1/ path searched correctly.