If you search for an mcp directory, you will quickly hit a taxonomy problem: a registry, a marketplace, and a vendor's own server page can all look like a directory, yet they mean different things. The official MCP Registry at registry.modelcontextprotocol.io is the primary surface, describing itself as Discover Model Context Protocol servers and publishing an API reference plus an open codebase. Its Recently Updated feed shows entries under dotted namespaces such as ai., cloud., co., com., dev., and io.github., each with a publisher/name path, semantic version, one-line description, and update stamp.
This post treats the mcp directory as an analysis object, not a bookmark. We will separate registry entries from vendor presence, inspect what a listing actually contains, and explain why namespaces are a claiming race. Then we will cover verifiability, listing drift, directory-native payments, server submission, testing a server from a listing, and what security evidence does or does not support. We will also place a single vendor studio in that landscape and close with FAQ and practical next steps.
Registry vs. Vendor Presence: Two Different Objects
If you searched for the MCP registry: it is registry.modelcontextprotocol.io, which labels itself "Discover Model Context Protocol servers." The API reference sits at registry.modelcontextprotocol.io/docs and the code at github.com/modelcontextprotocol/registry. Read those rather than a paraphrase.
The distinction the rest of this article rests on: a registry is a third party index of servers other people published. A vendor presence is that vendor listing only its own servers. They are not interchangeable, and conflating them is why a lot of MCP discovery advice fails in practice.
The phrase "mcp directory" is used loosely for both objects. No source reviewed here defines it, so defining it is this piece's job. This article will not rank directories: no ranking, traffic or install data exists in the sources reviewed. For a wider server list, see Where to Find More.
What a Registry Listing Actually Contains
Four fields carry the whole judgement: the publisher/name path, a semantic version, a one-line description, and an update stamp. In the registry's server.json schema, name and version are declared fields, and npm ownership is verified when mcpName matches the server name in server.json.
The feed is "Recently Updated", not ranked. There is no editorial pick and no ordering by quality, so position reflects recency only. On the captured page, every visible entry reads Updated 10/2/2026; that stamp describes one capture, not growth.
Two entries show the one-liner doing real work. io.github.SidneyBissoli/ibge-br-mcp declares 23 tools and names official APIs as its provenance. com.jasontally.mac/mcp states "No auth, no key." By contrast, io.github.ProAgentStore/platform reads as generic platform positioning. Naming a data source or a protocol tells a reader what the tool does before they install anything.
Namespaces Are a Claiming Race
The publisher path is the field worth reading twice. Visible families in the feed include ai., cloud., co., com., dev.* and io.github.*. Each carries a publisher path plus a name, and the namespace signals who is making the claim.
That creates structural tension. An io.github.* entry competes in the same feed as a paid domain under com., dev. or co.*. A GitHub org path and a registered domain are claiming the same slot in a reader's attention.
What the namespace proves is narrow. io.github.* ties a listing to a real, checkable GitHub account. A custom domain proves domain control, also checkable. Neither proves the tool works.
The two examples read differently. com.jasontally.mac/mcp reads as an individual shipping a narrow utility. cloud.hstgr.srv1024618.aval/trust reads as infrastructure with a billing model attached.
Decide deliberately. The namespace is chosen once and becomes part of the listing's identity.
What Makes a Listing Verifiable
Namespace is one signal; the description line is another. Listings that lead with a concrete price, a named protocol, or a named upstream source read as more verifiable than listings built on abstract positioning. That is an observation from the feed, not a measured result.
cloud.hstgr.srv1024618.aval/trust is the clearest case: payment backed trust scores for AI agents on Base (ERC-8004 draft) at $0.01 per check via x402. Price, chain, standard and mechanism in one line. io.github.SidneyBissoli/ibge-br-mcp names IBGE, a public statistics provider you can open and check. com.jasontally.mac/mcp names the IEEE registries for OUI lookups and states its access model: no auth, no key.
The mechanism behind per-call pricing is covered in HTTP 402 and x402 licence checks.
Apply the test: is there a price, a protocol, or a named upstream source, and can you verify it in under a minute? If not, treat the listing as unverified until you test the endpoint.
Listings Are Not Static
Verifiability assumes a listing holds still. It does not. On one captured page, io.github.ExaDev/agent-comms appeared three times at v8.13.3, v8.13.4 and v8.13.5. Three entries, three consecutive patch versions, one screen. A snapshot therefore goes stale within days, so any internal index or bookmark list must re-sync against the registry rather than being copied once and trusted.
Tool counts spread just as wide. io.github.Invarato/jarroba-tools advertises 128 deterministic tools, "Local, no network". Sibling packages declare 5, 11 and 4. io.github.SidneyBissoli/ibge-br-mcp declares 23. No field defines the unit, so 128 local deterministic tools and 4 wrappers around a remote API are not comparable quantities.
Pin versions when you wire a server into a client, and re-check the listing before upgrading: a patch bump can change tool behaviour without changing the description, and how Claude Code sees what is available depends on what the client actually negotiates.
Payments Are Already Directory Native
Pay-per-call is not a roadmap item. It is in the feed now: several captured entries sell a single check, not a subscription.
cloud.hstgr.srv1024618.aval/trust (the $0.01/check listing noted earlier) is the clearest case. com.agoraverify/agora-omega sells sanctions, MiCA, French KYB and AI Act checks in USDC via x402. io.github.Elimuaa/money-mind is pay-per-call in USDC via x402.
x402 reuses the HTTP 402 Payment Required status code, which is why a price can sit in a listing at all. An agent reads the quote from the response, settles, retries. No account, no key, no human.
For a developer, a per-call price is a verifiable number. Call the endpoint, read the 402 quote, compare it to the advertised figure. "Contact us" and free tiers with unstated limits cannot be tested that way. See The x402 Pattern: How Agents Pay for Tools Without a Human.
The limitation: per-call payment is a payment rail, not a quality signal. A $0.01 check is not more correct than a free one.
How to Submit a Server to a Registry
The submission shape lives in two places, and both move. Read the API reference at registry.modelcontextprotocol.io/docs and the codebase at github.com/modelcontextprotocol/registry; the field list changes, so do not work from a copied example.
1. Pick the namespace first. You are choosing between an io.github.* path tied to a real GitHub account and a custom domain you control. The namespace is part of the listing's identity and is painful to change later.
2. Write the one-line description for the feed. It is the only text most readers see. Name the data source, the protocol, or the price. Cut "platform" and "control plane".
3. Declare a real semantic version and expect to bump it. Consecutive patch versions of one server already sit on a single feed page, so version discipline is visible.
4. State the access model if it is unusual. "No auth, no key" costs nothing to say and does real work.
5. Verify the render. Read your own entry in the feed as a stranger would, then connect from an MCP client, not your dev shell. For the client-side setup, see where to find MCP servers to add when wiring the endpoint.
How to Test a Server From a Listing
A listing is a claim. A Streamable HTTP endpoint settles it.
curl -i https://moltlinestudio.com/api
# HTTP/1.1 402 Payment Required, x402 terms in PAYMENT-REQUIRED
That returns the price with no account and no human in the loop. Then paste https://mcp.moltlinestudio.com/<server> into Claude, Claude Code, Cursor, Codex CLI or any MCP client and confirm the tool list loads. If it does not, the entry is wrong, stale or gated.
This beats reading the one line description because the endpoint answers or it does not, regardless of how well the publisher wrote it.
Expect three failure modes: a 404 from a moved endpoint, an auth challenge where the listing claimed none, and a tool count that disagrees with the entry. Each is a reason to check the registry for a newer version. How to Run the Check scores the same way.
Start with mcp.moltlinestudio.com/, most tools need no key; see Where a Single Vendor Studio Fits for the full access model.
The Security Angle: What the Evidence Actually Supports
The endpoint test is the only security evidence you can verify directly today. For how to structure that review, see the MCP Server Security: Evaluation Checklist for Production.
The page at practical-devsecops.com/mcp-security-statistics-2026-report is titled as a report on CVEs, vulnerabilities and breach data. The retrieved extract contains only course catalogue copy: no CVE counts, no breach figures. No figure from that page is quoted in this article. Re-fetch the report body yourself before citing anything from it.
What it does confirm is a paid training market. Certified MCP Security Expert (CMCPSE) is listed at $699, covering tool poisoning, prompt injection, supply chain security and agentic AI defenses. Certified Agentic AI Security Expert (CAASE) is listed as coming soon.
The second gap: arXiv 2603.05637v1, "Real Faults in Model Context Protocol (MCP) Software", shows reliability research is being published, but only the title was retrieved. Treat it as a pointer to read, not a citable finding.
The honest state of 2026: security evidence for a specific server comes from testing the endpoint and reading the source, not from a published aggregate.
Where a Single Vendor Studio Fits
The same test-first rule applies to vendor pages. Moltline is not a directory. It lists nothing but its own 22 servers and 160 tools. It does not index anyone else's servers and does not host anyone else's tools. The pattern the registry feed rewards is a concrete endpoint, a concrete access model and no signup wall, and that is what Moltline builds to.
110 of the 160 tools are free forever, with no account, no API key and no signup, reachable at mcp.moltlinestudio.com/. The other 50 unlock with a $19/month All Access licence, paid in cryptocurrency. /api serves a live HTTP 402 x402 challenge, so an agent can read the price and settle on chain without a human.
Non-commercial on-ramp: 138 SKILL.md skills open on GitHub at github.com/GarphenGate/moltline-oss, plus a free SKILL.md linter and a free agent-readiness checker. One person runs all of it. See also Where Moltline Fits: Tooling, Not a Builder.
FAQ
What is the official MCP registry?
registry.modelcontextprotocol.io, docs at /docs, source at github.com/modelcontextprotocol/registry. A third party index, not a vendor page.
Is an MCP directory the same as a registry?
No. A registry holds many publishers' listings; a vendor page holds only its own servers. Moltline is the second kind: 22 servers, 160 tools, nothing else.
How do I get my server listed?
Read registry.modelcontextprotocol.io/docs, pick a namespace, name a source, protocol or price in one line, declare a semantic version, submit, verify the rendered entry.
How do I test a server from a listing?
Follow the steps in How to Test a Server From a Listing: paste the Streamable HTTP URL into your client and, for priced endpoints, run curl -i /api.
Are there CVE or breach statistics?
Not in the sources reviewed. The practical-devsecops statistics page returned course catalogue copy only; the arXiv MCP faults paper, title only. State the gap, do not guess.
Is there a best MCP directory?
No ranking, traffic or install data was available, so none is offered. Use the feed, check each listing's four fields, test the endpoint.
What to Do Next
Read five entries on registry.modelcontextprotocol.io as a stranger would: publisher path, version, one-line description, update stamp. You will sort strong listings from weak ones in about a minute.
Then test the endpoint before trusting it. Paste the Streamable HTTP URL into Claude Code, Cursor or Codex CLI. For priced servers, run curl -i against the /api path and read the 402 challenge.
If you are publishing, the three steps in How to Submit a Server to a Registry apply: namespace, description, honest version bumps.
Treat missing evidence as missing. No directory ranking data and no aggregate CVE numbers were available for this piece. Saying so beats quoting a number you cannot check.
For a concrete endpoint to test the method against, mcp.moltlinestudio.com/ requires no key for most tools, see Where a Single Vendor Studio Fits.
Conclusion
An MCP directory is not a static badge. It is a registry and a marketplace feed, where namespaces are claimed, versions move, and payments can sit beside listings. To judge any entry, check four things: publisher path, version, description, and update stamp. Then test the endpoint yourself, including the 402 challenge for priced servers. That habit turns a listing from a promise into evidence.
The four-field habit and the curl test in What to Do Next are the fastest path from listing to working tool.