MCP Registries in Mid-2026: One Upstream Won Mcpxhub.io, the vibe-coded Model Context Protocol (MCP) server catalog that indexed 26,708 servers from 47,246 repositories, has been deleted and replaced with 1,007 redirects to a rebuilt catalog at catalog.agentage.io, which holds about ten thousand fewer servers. The official MCP Registry at registry.modelcontextprotocol.io, with its API frozen at v0.1, lists roughly 16,967 published servers as of July 16, 2026, all verified through publisher ownership proof and signed records, marking a shift from scraped breadth to verified trust. Catalogs like PulseMCP, Glama, and agentage now source from the same upstream registry, adding editorial, derived data, or computed grades, and server authors can publish once to appear everywhere within a day. 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 https://catalog.agentage.io/mcp . 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 https://registry.modelcontextprotocol.io/ went live at https://registry.modelcontextprotocol.io 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 https://www.pulsemcp.com/ 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 https://glama.ai/mcp/servers 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 https://catalog.agentage.io/mcp 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 https://github.com/mcp is a separate curated catalog with its own pipeline its stated plan is interop with the open registry, not mirroring it . Smithery https://smithery.ai/ 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 freeloading. Then I read the registry’s ecosystem vision https://github.com/modelcontextprotocol/registry/blob/main/docs/design/ecosystem-vision.md 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.