In May I wrote that my vibe-coded catalog indexed 26,708 Model Context Protocol servers, and that the next move was a pivot from breadth to trust. Last week I finished that pivot by deleting the catalog. mcpxhub.io now answers with 1,007 redirects, one per server page, all pointing at the rebuild: https://catalog.agentage.io.
The rebuild holds about ten thousand fewer servers. This is the story of why that’s an upgrade.
The sequel to “I Vibe-Coded an MCP Catalog. Coding Was the Easy Part.” The trust pivot, delivered.
You know how a scraped catalog works because nearly every MCP directory of 2025 worked that way: crawl GitHub, guess which repos are servers, dedupe, summarize, ship a big number on the homepage. Mine scanned 47,246 repositories to claim 26,708 servers. The number was the moat.
Except it wasn’t. A crawler can verify that a repo looks like an MCP server. It cannot verify that anyone owns it, that the npm package belongs to the repo, or that the hosted URL is really operated by the name on the tin. Scraped breadth is a pile of unverifiable claims with great SEO.
Meanwhile the official MCP Registry went live at https://registry.modelcontextprotocol.io (still formally a preview; API frozen at v0.1). It holds roughly 16,967 published servers as of July 16, 2026, and every single one got there the same way: a publisher proved ownership of a namespace and signed a record. Nobody crawled anything.
26,708 scraped beats 16,967 verified on a homepage. It loses everywhere else.
So I killed the scraper, pointed the crawler at the registry’s /v0.1/servers endpoint, and sunset mcpxhub with a 301 for every slug. The smaller number is the feature.
The real shift isn’t my catalog; it’s that catalogs are becoming views of the same upstream, each adding a different kind of value on top. PulseMCP lists integration with the official MCP Registry among its data sources and layers an editorial model over it: curated picks, use-case writeups, a newsletter.
Glama calls itself a superset that “ingests and re-publishes everything”, then adds data derived from running servers in its own sandboxes, plus paid hosted connectors. And agentage crawls /v0.1/servers daily and adds computed grades and health probes. Same upstream, three different lenses.
Not everyone is fully in. GitHub’s MCP registry is a separate curated catalog with its own pipeline (its stated plan is interop with the open registry, not mirroring it).
Smithery publishes into the registry (ai.smithery/* namespaces) and sells managed hosting and billing on top, but has never stated it sources from it; mcp.so and mcpmarket.com are silent about sourcing. Convergence is the settled direction, not a completed migration.
For you as a server author, the payoff is concrete:
Publish once, appear everywhere. The five-directory submission grind of 2025 is ending.
One mcp-publisher publish and your server shows up in PulseMCP, Glama, and agentage within a day, carried by their ETL jobs, with zero further submissions. I watched it happen to my own servers; the receipts are below.
The registry hosts metadata, never artifacts. Your server.json record must point somewhere real, and there are precisely two options.
Door A: a package on an allowlisted public registry: npm, PyPI, NuGet, Cargo, OCI images, or MCPB binaries. The base URLs are pinned (registry.npmjs.org, pypi.org, and so on); private mirrors are rejected outright. Ownership is proven inside the artifact: for npm, a mcpName field in your package.json must match the server.json name exactly.
Door B: a remote URL. A publicly reachable streamable-http (or SSE) endpoint in a remotes array. No package anywhere. Reachability plus namespace proof stands in for the artifact.
My MCP-search server does both from a single record: io.agentage/mcp-catalog ships as @agentage/catalog-mcp on npm (Door A, stdio) and as the hosted endpoint catalog.agentage.io/mcp (Door B), one server.json, both doors.
The schema is stricter than you’d guess. Descriptions are capped at 100 characters, and that’s enforced, not advisory (commit #70 in my repo is literally “registry caps description at 100 chars”). Names must match namespace/name with the namespace proven via GitHub OAuth or a domain challenge. It's the opposite of a scraper's permissiveness, on purpose.
When I started re-serving registry data with my own metadata on top, it felt vaguely like free. Then I read the registry’s ecosystem vision doc. Verbatim:
Subregistries “add value to the registry ecosystem by providing curation, or extending it with additional metadata.” The official registry “expects a lot of API requests from ETL jobs from these subregistries.” And: “we expect clients pull from subregistries.”
The design even reserves the mechanism: enrichment lives in namespaced _meta blocks, so every downstream catalog annotates the same canonical record instead of forking it. Aggregating isn't parasitism; it's the deployment model. The registry is upstream infrastructure the way npm is: nobody browses npm, everybody builds on it.
The registry is still a preview, and data resets are possible. I built on it anyway; re-publishing is one command, so betting on the direction costs almost nothing.
My rebuild takes this literally, and the pattern is open to anyone. It consumes /v0.1/servers and re-serves the same v0.1 API contract, with its enrichment under a namespaced _meta key (io.agentage.catalog/v0).
It is itself published into the registry as io.agentage/mcp-catalog, the same way PulseMCP and Smithery publish their own servers under their namespaces. A catalog that lives inside the catalog it serves is the cleanest compliance test there is: if the contract drifts, you break yourself first.
Here’s the recipe I wish someone had written before I reverse-engineered it. This is Door B, the hosted-URL path, and the whole thing is four steps.
1. Describe it. mcp-publisher init scaffolds server.json. For a hosted server you need four fields and no packages at all:
{ "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json", "name": "io.agentage/mcp-catalog", "description": "Search the official MCP registry: 15k+ servers with trust grades, stars, tools, install config.", "version": "1.1.0", "remotes": [{ "type": "streamable-http", "url": "https://catalog.agentage.io/mcp" }]}
*server.json for a hosted server: four fields, no *packages.
That description is 95 characters. You have five to spare.
2. Prove the namespace. Publishing under io.github.<you>/* costs one GitHub device-flow login. A branded namespace like io.agentage/* requires proving you control the apex domain. Publish either a DNS TXT record (v=MCPv1; k=ed25519; p=<your-public-key>) or the same key served from https://yourdomain/.well-known/mcp-registry-auth, then run mcp-publisher login dns (or http).
The HTTP verification path carries SSRF risk; the DNS TXT record is the lower-risk default. Generating the ed25519 keypair needs OpenSSL 3; macOS’s bundled LibreSSL can’t.
3. Ship it. mcp-publisher validate, then mcp-publisher publish. One signed record lands in the registry.
4. Do nothing. The ETL wave does the distribution. io.agentage/mcp-catalog went live on July 6, 2026 exactly this way; PulseMCP lists it today, and Glama picked up my memory server (io.agentage/memory) through the same pipe. I never filled in a form on either.
If your server needs auth, the schema handles it without leaking secrets: remotes[].headers carries templates flagged isSecret, and URLs accept {variables} the client fills in. Smithery's registry entries use exactly that shape.
Here’s the honest limit of everything above: the registry proves who published a server, and nothing else. It doesn’t know whether the code is maintained, licensed, healthy, or safe. Ownership proof is not safety: a verified namespace can still register a look-alike mcp-server-postgress, or ship malicious tools under its own real name.
That’s deliberate; a canonical upstream should be neutral. It’s also the gap subregistries exist to fill, and where the interesting competition moves next.
Each subregistry fills the gap with what it has. Smithery’s managed hosting buys convenience and concentrates risk in equal measure. The June 2025 path-traversal flaw in its hosting layer (publicized that October) gave the attacker access to 3,000+ hosted servers.
For the rebuild I stuck to computed signals:
Different trade-offs, same gap: the registry tells you who published; the layer above tells you whether you want it.
Trust is the moat now. Breadth is acurl away for anyone.
What ownership verification plus computed trust still can’t tell you: whether a server’s tools are actually callable by real models, end to end, across vendors. That’s measurable, I’ve started measuring it, and it’s the next article: a cross-model routability score for MCP servers.
The scraping era gave us big numbers. The registry era gives us one number that means something. I deleted 26,708 servers and I’d do it again this afternoon.
If you’re publishing an MCP server, or building on the registry, ping me; happy to compare notes.
Volodymyr Vreshch builds https://catalog.agentage.io/mcp, a registry-native catalog of Model Context Protocol servers, and writes about agents, MCP, and developer tooling at https://vreshch.com. Senior Software Engineer at Microsoft. On GitHub: https://github.com/vreshch/
MCP Registries in Mid-2026: One Upstream Won was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.