Dexio / how-we-build-dexio / growth

Listing a remote MCP server in the directories

How we listed https://app.dexio.wiki/mcp. Get the server right first, since several directories sign in to it and grade it: remote-mcp-server-with-oauth.

What it is

• The official MCP Registry. A server.json names the server in reverse-DNS form of a domain you own (ours is wiki.dexio/dexio), with a version and a remote URL with transport streamable-http. You prove the domain with an Ed25519 public key in a TXT record (v=MCPv1; k=ed25519; p=<key>) and publish with the registry's CLI.
• Directories that copy the registry: mcp-marketplace.io and Glama picked ours up by themselves; PulseMCP says it will once its submissions reopen.
• Glama: claim the listing with a TXT record. Its health check needs to authenticate, so give its test profile an API key from a test account. It grades every tool.
• Smithery: publish by URL under your own namespace. Its scan signs in through your OAuth with a test account and lists the tools it found.
• LobeHub: owners publish through its CLI (npx @lobehub/market-cli) from a manifest; we build ours from the server's live tools/list.
• Lists that take a pull request or a form: awesome-mcp-servers takes only servers with a public repository and sends remote-only ones to awesome-remote-mcp-servers; mcpservers.org has a form with free review; allmcps.com takes submissions from agents through an API its llms.txt describes, and verifies ownership by TXT record; Context7 indexes your llms.txt. mcp.so's free form needs a public repository.
• Reviewed directories:
  • Claude: submitted from the developer portal on any paid plan, Pro and Max included; the listing belongs to the account that submits it. It asks for a name, tagline, description, categories, docs, privacy and support links, an icon, a permanent slug, use cases, the auth mode (dynamic client registration is supported), data handling, a test account with real-looking data, and confirmation that every tool was run as a custom connector or in MCP Inspector. Every tool needs a title and a description that says when to use it.
  • ChatGPT: submitted from the OpenAI Platform dashboard after identity verification. It asks for screenshots, test prompts with expected answers, demo credentials without MFA, a token served at /.well-known/openai-apps-challenge, a content security policy, and test cases passing on web and mobile. Every tool needs openWorldHint.
  • Cursor: a publisher application with a plugin repository, reviewed by hand.

What to expect

Nobody publishes signups per directory, and founders who post are the ones with something to show, so these lean high:

• Claude: two founders reported a launch bump, about 60 registrations in two days for one and 115 sign-ups in a day for the other, then a trickle as newer listings pushed theirs down.
• ChatGPT: by OpenAI's own guide, a published app is found by direct link or by searching its exact name, unless OpenAI picks it for wider distribution. What it gives is a one-click connection for people who already know you.
• Smithery's public use counts were near zero for most hosted memory servers when we checked. They count only connections through Smithery's own gateway.
• For a new domain, much of the value is the link back to your site, and directories differ: some links are followed, some carry nofollow, and some become followed only if you show their badge on your site. Check each one.

How to build it

1. Fix the server before anyone grades it: OAuth with dynamic client registration, iss on redirects, client ids accepted from a Basic header, GET answering 405, a title and when-to-use text on every tool, and openWorldHint set.

2. Make a test account with a small, realistic wiki for reviewers and health checks. Mint the checker's key through your own device sign-in, named for the checker, so you can revoke it alone.

3. Publish to the official registry first. Put the TXT record on the apex beside SPF and any other verification values, and remove the old one when the key changes, since a stale record is tried first.

4. Claim the listings that copied the registry.

5. Then the ones that take a URL or a form, then the reviewed directories.

6. Leave every verification record published; several directories check again later.

7. Record where each sign-up came from (referrer, or which client's OAuth created the account), so each listing's effect shows in your own data.

8. Add small watcher jobs for listings under review: check the public page daily, say when it is live and whether its link is followed, then remove the job.

Verify

• Each listing loads, shows your tool count, and links to your site. Check the link's rel.
• Directories that run a health check show your server as healthy.
• A sign-up through a listing shows up attributed to it.

Pitfalls we hit

• Smithery's scanner registers with client_secret_basic and sends its client id only in the Basic header. The MCP Python SDK reads it only from the form, so token requests failed with "Missing client_id" until we copied the id across.
• Smithery's first scan timed out at the sign-in step after the fix; publishing again worked.
• LobeHub's CLI signs in through a redirect to localhost on the machine running it. On a headless server, open the link elsewhere, copy the failed localhost address back, and replay it there within the time limit.
• Some directories pause submissions without a date. Watch them rather than waiting.