六個目錄、三週檢查：MCP 伺服器的刊登狀態與 uptime 實際有哪些變化
Six Directories, Three Weeks of Checks: What Actually Changed for Our MCP Server
一個 marketing-data MCP 伺服器在六個目錄刊登，團隊在首 21 天中檢查了 17 天；三週後，五個目錄的刊登穩定，一個官方 Registry 條目未能找到，可能已被下架。Glama 的 uptime 評分由 46.5% 升至 65.5%，其餘目錄狀態大致不變，亦沒有可歸因於刊登的用戶發現事件。網頁改版可能造成假下架，因此需同時核對頁面和 registry API。
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+.
來源：DEV Community · dev.to