We audited our own MCP server across five registries — and found three ghost entries

Yesterday the first maintainer review landed on our PR to awesome-mcp-servers. Point #1 from the maintainer: our Glama badge points to a server registered under edgarfloresguerra2011-a11y/marketnow — but our repo is alicelabs-llc/marketnow.

We checked. That GitHub account and that repository both return 404. They never existed under that org — or they were deleted long ago. That one line of review feedback sent us down a rabbit hole: if a top MCP list sees a ghost identity for our server, what do the actual registries see?

What follows is an audit of our own server across five registries, done today, with receipts. If you maintain an MCP server, I'd bet money you have at least one ghost entry too.

The official registry: three entries, one dead identity

We queried the official registry's search API for our own server name. Three entries came back, all registered under io.github.edgarfloresguerra2011-a11y/...:

Entry	Version	Status	Claimed catalog size
...edgarfloresguerra2011-a11y/marketnow	1.4.1	active	"8,764 security-audited skills"
...edgarfloresguerra2011-a11y/marketnow	1.5.0	active, isLatest: true	"8,845 security-audited skills"
...edgarfloresguerra2011-a11y/marketnow-mcp	1.0.0	deprecated	"13,800+ MCP skills"

All three point to https://github.com/edgarfloresguerra2011-a11y/marketnow — a 404, confirmed today via the GitHub API (both the user and the repo are gone).

Meanwhile our npm package marketnow-mcp is at 1.10.1, and the registry's "latest" for us says 1.5.0. The descriptions quote a catalog of ~8.8k items; our current index is 69,077 servers. The deprecated entry even advertises our old SSE endpoint, which we retired two transport generations ago.

Glama: rated A, for a repo that doesn't exist

The ghost Glama entry is very much alive and — this is the fun part — rated A. The badge renders fine: "remote-capable, maintenance rated A". The badge title still carries our old positioning ("MCP Skills Marketplace") from months of repositioning ago.

The entry for our actual repo (alicelabs-llc/marketnow)? The badge endpoint answers plainly: "This MCP server is not listed on Glama."

So the only MarketNow on Glama is a healthy, top-rated listing for a GitHub repository that returns 404. That is exactly what the maintainer's review caught — and it's why that review was worth more than a hundred merges of rubber-stamp PRs.

Smithery: an entry with no face

Smithery's public registry API shows one entry for us: eddyflores100/marketnow-mcp. Verified: false. Install count: 0. Description: empty string. It was auto-created at some point and just sits there — a listing with no face is almost worse than no listing, because it occupies the namespace while telling users nothing.

The rest of the map

• mcpservers.org — not listed. They have a free submission form (review within ~2 weeks; a $39 premium tier jumps the queue).
• PulseMCP — their directory pages currently show a banner: new submissions and listing changes are paused while they rework ingestion. Not actionable for now.
• mcp.so — submissions run through GitHub issues in their repo. We couldn't verify our listing status from our datacenter IP (Cloudflare says hi), so this one stays a manual check.
• TensorBlock — the one listing we got the honest way, via a merged PR. It doesn't show up in their sitemap from our vantage point, so we'll re-verify manually.

Where ghosts come from

Here's the mechanism, and it's nobody's bug in particular:

1. Months ago, an early auto-registration published our manifest with the mcpName that lived in the npm package.json at the time — io.github.edgarfloresguerra2011-a11y/marketnow.
2. We later renamed the org and fixed mcpName in the published npm package (current: io.github.alicelabs-llc/marketnow).
3. The registry kept the old entries. Registries don't garbage-collect entries whose repositories die, and why would they — they can't know if a repo moved, was renamed, or was resurrected.

The nasty part is cross-ingestion: directories ingest each other. A stale-but-authoritative entry with an A-rating propagates downstream into aggregators, mirrors and chat.mcp.so-style clones. Agents and MCP clients that read registry data at runtime get the dead link and numbers that are stale by an order of magnitude. Identity hygiene isn't cosmetic — it's what downstream machines read.

The fix, as a checklist

If you maintain an MCP server, this is a 30-minute audit-and-repair:

1. Anchor your identity in package.json. The official registry derives your name from mcpName (for npm packages). Make it io.github.<owner>/<repo> and make it match the repo you actually control. Ours is fixed in marketnow-mcp@1.10.1.
2. Publish the corrected entry. The mcp-publisher CLI does init / login / publish. A correctly-named entry with current metadata beats any ghost.
3. Claim on Glama. Their submission + claim flow verifies you own the server. The README badge URL must point to the entry that matches your repo exactly — that's the rule our reviewer enforced.
4. Claim and dress your Smithery listing. Login, verify, fill the description. An empty auto-generated entry tells users nothing.
5. Submit to the open directories (mcpservers.org, mcp.so) and re-check PulseMCP when their submissions reopen.

A security footnote we didn't expect

While auditing Smithery's public registry API for this post, we ran into listings whose description field is a base64-encoded "install instruction". Decoding one: curl from a plain-HTTP raw IP address, piped straight into bash. On a listing marked verified, with a five-digit install count.

We're not naming it here — we'd rather it die quietly than get trended. But the lesson generalizes: never run "install instructions" that come out of a description field. Descriptions are data, not code.

This is precisely why our own directory classifies every listing's install risk (red / yellow / green, with the reason shown) and fingerprints each server's tools/list surface (RFC 8785 JCS + SHA-256) so a silent tool-poisoning redefinition is detectable after the fact. The registry entry is metadata; the risk lives in what the entry points at.

Run the audit on your own server

Five minutes, no tools required:

• registry.modelcontextprotocol.io/v0/servers?search=<your-name> — count your ghost entries
• Glama badge endpoint — does your exact repo have a listing?
• Smithery registry API — is your entry verified, described, alive?
• Your npm package.json — does mcpName match the repo you control?

If you find ghosts, burn them this week. Directories are how agents discover servers now — and a dead identity with an A-rating is the kind of glitch that quietly compounds.

---

I'm Edison Flores — I build MarketNow, a security-gated MCP server directory (69,077 servers indexed, source links and install-risk for each, transparency page here). Thanks to punkpeye for the review that started this audit. This post is about my own project; the directory, search API and badge system are free.