There are more than 10,000 public MCP servers, the SDKs are downloaded 97 million times a month, and only 8.5% of servers use OAuth. Somewhere in that pile is the deploy tool your agent will use to ship to production — found, most likely, by guessing keywords into an npm search box. On September 6, 2026, a bootstrapped directory called AI Agents Listing launched with a different bet: index agents, MCP servers, and skills together, review every listing by hand, and expose the whole catalog over MCP itself so agents can query it directly.
The question this post answers is concrete: if you run a self-hosted platform and need to discover — or be discovered as — a deploy-capable MCP server, what does this directory actually change? Here is the short version up front, scored against the trust criteria a deploy tool has to clear:
| Trust criterion | npm / GitHub guesswork | Official MCP registry | AI Agents Listing |
|---|---|---|---|
| Scale indexed | 13,000+ servers scattered across packages and repos | ~9,650 servers, namespace-authenticated | Curated subset, human-reviewed |
| Tells you which agent a server works with | No | No | Yes — cross-linked agent/server/skill pages |
| Human verified the listing is real | No | Namespace check only | Yes — every submission reviewed by a person |
| Agent-queryable without a login | No | API, not an MCP tool | Yes — public MCP endpoint plus llms.txt and RSS |
| Paid placement separated from rankings | N/A (no rankings) | N/A | Yes — paid slots labeled, rankings engagement-computed |
| Code audit or CVE scan | No | No | No — review is editorial, not a security audit |
That last row is the honest boundary, and this post keeps it visible throughout. A hand-reviewed directory raises the floor on discovery fraud — fake listings, dead servers, miscategorized tools — but it does not audit the code you are about to hand production credentials to. What follows is what launched, why discovery (not supply) is the gap, what "the catalog is itself a tool" buys a platform deciding how its deploy surface gets found, and a vetting checklist for the part no directory can do for you.
What launched on September 6
AI Agents Listing went live on September 6, 2026 out of Vancouver, Canada, built by solo founder Nick (publishing as Nick Launches) and operated by GrubGuru. The launch announcement frames the problem as a three-layer stack catalogued in three places that do not reference each other: agent directories ignore MCP servers, MCP registries ignore agents, and skills have had no directory at all beyond repository readmes.
The directory models all three layers as one index. Every listing gets its own indexable page with a description, category, setup details, and links. An agent's page lists the MCP servers it works with and the skills that extend it; an MCP server's page lists the tools it exposes and the skills that use it. Search, categories, tags, curated collections, alternatives, and side-by-side comparisons run across all three layers at once.
Three properties matter for the trust story. First, listing is free and every submission is reviewed by a person before publication; a free listing asks for a badge on the maker's site in return. Second, the paid side is a published, one-time upgrade menu — do-follow link, faster review, featured placement — and the founder's rule is explicit: "A list you can buy your way into is the list nobody uses." Rankings on the leaderboard and trending lists are computed from engagement, upvotes, and verified reviews, never from payment. Third, the directory is readable by the agents it catalogues: a public MCP endpoint lets any MCP-compatible client search listings, pull trending tools, discover by category, find alternatives, and compare two tools without a login, with an llms.txt file and RSS feeds covering non-MCP consumers.
The founder previously built nicklaunches.com, a launch directory described as growing from an empty database to a widely referenced site in four months — the same free-listings-first playbook, now applied to the agentic stack. It is a bootstrapped, self-hosted, one-person project, which is both the appeal (no investor pressure to sell the rankings) and the durability question (covered honestly in the limits section below).
Why discovery is the gap, not supply
Nobody in 2026 is short of MCP servers. Anthropic's December 2025 ecosystem update counted more than 10,000 active public servers and 97 million-plus monthly SDK downloads; an independent May 2026 tally put it at 13,000+ servers on npm and GitHub with 400% year-over-year growth in new registrations. The official registry at registry.modelcontextprotocol.io holds roughly 9,650 of them, and company-operated servers grew about 873% — from 425 to over 4,100 — in under a year. Adoption followed: Stacklok's 2026 survey found 41% of software organizations running MCP in some form.
Governance consolidated just as fast. Anthropic donated MCP to the Agentic AI Foundation, a Linux Foundation directed fund, on December 9, 2025, alongside Block's goose and OpenAI's AGENTS.md. Google's Agent-to-Agent protocol joined the same foundation on August 17, 2026. The July 2026 MCP spec made the protocol core stateless, closing the load-balancing gap that used to favor bespoke function calling. In September, the foundation launched the MCPA certification for MCP practitioners. The protocol layer, in other words, is standardizing under neutral governance while supply explodes.
Discovery never kept up. Finding the right server is still, in the dev.to tally author's words, "search npm with guesswork or dig through folders on GitHub." The official registry authenticates namespaces but says nothing about whether a server works, what it works with, or who vouches for it. There is no provenance signal anywhere in the default path: download counts measure popularity, not trustworthiness, and a deploy tool with a convincing readme is indistinguishable from a credential harvester until you read the code. That is the gap a cross-linked, reviewed catalog is trying to fill — not more servers, but a reason to believe the one you picked.
Anatomy of trusting a deploy-capable MCP server
A deploy MCP server is the highest-stakes tool you will hand an agent. It holds production credentials, mutates live infrastructure, and its failure mode is not a wrong answer but a bad rollout — or a leaked secret. So the baseline it inherits is worth stating plainly, because it is grim:
- Only 8.5% of MCP servers use OAuth; 53% rely on long-lived static API keys, per Astrix Security's audit of more than 5,200 servers, summarized across multiple 2026 reports.
- Roughly 38–40% of public MCP servers run with no authentication at all, per converging research from Wiz, Bloomberry, and Censys.
- More than 30 MCP-related CVEs were filed in a single 60-day window in early 2026, and Trend Micro found 492 internet-exposed MCP servers with zero authentication.
- 15.4% of servers ship no public source code at all, and one skills marketplace audit found roughly 20% malicious listings.
Against that baseline, be precise about what hand review proves and what it does not. A human reviewer can confirm the server exists, does roughly what the listing claims, links to real documentation, and declares which agents and skills it is compatible with — knocking out dead servers, miscategorized tools, and crude impersonations. A human reviewer does not read every line of the server's code, scan it for CVEs, verify its OAuth implementation, or re-audit it after every update. Editorial review is a filter on listing fraud, not a certification of runtime safety. Any directory that blurs that line is selling something no listing fee can buy — and to AI Agents Listing's credit, its launch materials claim review, not audit.
That distinction sets up the real value proposition: the directory compresses the discovery half of trust (is this thing real, maintained, compatible, and used by people I can inspect?) so you can spend your verification budget on the runtime half (code, auth, scopes) covered by the checklist at the end.
The catalog is itself a tool
The launch detail with the longest tail is the public MCP endpoint. A developer can already browse cross-linked pages; an agent can now do the equivalent over the protocol: search listings, retrieve trending tools, discover by category, find alternatives, and compare two tools — without a login, from Claude Code, Cursor, or any MCP-compatible client.
Walk through what that buys in the deploy-server case. Today, an agent asked to "find a tool that deploys a container to my cluster" has no grounded move: it can hallucinate a package name, guess at npm, or ask the human. Against a queryable catalog, the flow becomes mechanical: search the deploy category, pull the two finalists' tool lists and declared agent compatibility, compare them side by side, and return the comparison with links the human can verify before any credential is granted. The discovery step becomes inspectable — the agent shows its work from a shared index instead of asserting from weights.
For a self-hosted PaaS deciding how its own deploy/rollback surface gets discovered, this inverts the default. The question stops being "how do we get developers to find our docs" and becomes "is our tool surface legible to the index the agent already queries" — a structured listing with an accurate tool list, declared compatibility, and a setup page, sitting next to every alternative with a comparison view one call away. Directories that agents can read are the new SEO for infrastructure tools, and the llms.txt plus RSS fallback means even non-MCP consumers get the same structured feed.
Directories as distribution
There is a precedent for this pattern, and PaaS operators already know it: the template catalog. Railway templates, Render's one-click deploys, Heroku's old button — a deploy target's template gallery was never just documentation. It was a distribution channel. Getting listed meant inheriting the platform's discovery traffic, its standing-start trust ("it is in the official gallery"), and its reviewers' implicit compatibility check. Teams chose frameworks and add-ons substantially through those galleries.
MCP server directories are positioned to become the same channel for agent tools. If an operator's agent discovers deploy targets through a catalog its client already queries, then the listing page is the top of the adoption funnel in a way a GitHub readme never was: categorized, comparable, review-bearing, and reachable without leaving the agent session. That raises the bar for what a listing must disclose — and a deploy server's page should be held to the infrastructure standard, not the weekend-project standard:
- The exact tool list the server exposes (deploy, rollback, logs, status — named, not "and more").
- The auth mechanism (OAuth with scoped tokens, or static keys — stated, not implied).
- Minimum scopes and what each tool can mutate.
- Source repository, license, and update cadence.
- Declared compatibility: which agents and clients it has been tested against.
- A link to the rollback story — because a deploy tool without a documented undo is a liability with a listing.
A directory that normalizes these six fields across listings does more for deploy-tool trust than any single review could: it makes the absence of an answer visible. The server that leaves "auth mechanism" blank next to one that says "OAuth, least-privilege scopes" has told you everything, without a reviewer writing a word.
Honest limits and the vetting checklist
Before the checklist, the limits, stated as the directory's own materials imply them. Hand review happens at submission time; it does not continuously re-verify. Rankings derive from engagement, upvotes, and verified reviews — gameable signals, however honestly computed, and "verified review" is only as strong as its verification. The project is solo, bootstrapped, and self-hosted: that is independence from ranking-buyers, and it is also a bus factor of one for the index your agents may come to depend on. None of this is disqualifying. All of it belongs in the decision.
So here is the part no directory outsources — the six checks to run before any deploy-capable MCP server gets production credentials, however it was discovered:
- Read the auth code path. OAuth with short-lived, scoped tokens is the bar only 8.5% of servers clear. Static keys in environment variables are the common case — acceptable for a trial, not for standing production access without rotation.
- Confirm public source and scan it. 15.4% of servers publish none; that is disqualifying for infrastructure tooling. For the rest, check for flagged CVEs and unauthenticated endpoints before first run.
- Scope the credentials to the tool list. Grant exactly the tools the listing names, at the minimum privilege each needs. If the server demands one broad token for deploy-plus-logs-plus-admin, that is the finding.
- Verify compatibility yourself. Cross-linked "works with" pages are a starting claim, not a test result. Run the server against your actual client and confirm the tool calls behave before the agent session that matters.
- Test the rollback first. Deploy a canary, then roll it back through the same tool surface. A deploy tool whose undo path you have never exercised is a write-only system.
- Pin and watch. Pin the server version, subscribe to its releases and the directory's listing (RSS exists for this), and treat silent listing changes the way you would treat silent dependency updates — with suspicion.
Directories compress discovery; checklists compress verification. The ecosystem needs both, and conflating them — treating "it is listed" as "it is safe" — is the failure mode to name out loud.
The agentic stack spent 2026 standardizing the protocol and exploding the supply: neutral governance under the Agentic AI Foundation, 97 million monthly SDK downloads, ten thousand servers and climbing. AI Agents Listing's launch bets that the next bottleneck is knowing which server to trust — and that the answer is a catalog reviewed by humans and readable by agents. For deploy tooling, that is half the trust equation, and the half the ecosystem was missing. The other half still runs on your checklist, your scopes, and a rollback you have actually tested.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. AI agents are first-class operators here: machine-readable infrastructure state is the whole point. Star the repo on GitHub or deploy your first app today.



