Where an MCP server actually gets discovered in 2026 (and what to skip)

#ai #opensource #mcp #devtools

We shipped an MCP server for our product in a single afternoon. Getting it found took longer. Here is the honest map of the channels, in the order that produced results.

1. The install path is the product

An agent does not read your landing page first. It tries a command. If npx -y @tapacapi/mcp fails, nothing downstream matters. Two things made the difference for us:

Publishing on npm (registry entry + bin field) so the command resolves with zero config.
Shipping the same server over streamable-http so a client can point at a URL instead of installing anything.

Both are worth doing. The npx path is what most agents try; the hosted endpoint is what survives sandboxed environments where npx is unavailable.

2. Agent-facing manifests beat marketing copy

llms.txt, SKILL.md and a plugin manifest are boring files, but they are the ones a model actually ingests. The rule we follow: put the install command, the tool names, the arguments and the "works without a key" behaviour in the first screen of text. Anything an agent has to guess, it guesses wrong.

3. GitHub is still the discovery layer

Our traffic does not come from directories, it comes from GitHub search and from the awesome-lists that agents read. A PR adding one line to a big MCP list took five minutes and is the only channel where the listing is verifiable: a public URL, a number, a diff.

What we skipped:

Any catalog with a submission fee. One wanted $39 for a listing that agents would only see if they already knew the server name.
reCAPTCHA-walled directories. If the only path is a puzzle meant for humans, that is a signal about the expected volume.
Anything requiring OAuth we did not own. Time-boxed at ten minutes, then marked blocked and never revisited.

4. The official Docker registry is open to pull requests

Docker's MCP registry accepts remote servers with no Docker image and no build: three small files (server.yaml, an empty tools.json for dynamic tool discovery, and a readme.md) in a folder under servers/. The entry then shows up in the MCP catalog and in Docker Desktop's toolkit.

Our PR for a remote server, headers-based auth instead of OAuth:

name: tapac
type: remote
dynamic:
  tools: true
remote:
  transport_type: streamable-http
  url: https://example.com/mcp
  headers:
    Authorization: "Bearer ${MY_API_KEY}"

That single file is the whole submission. If you are building an MCP server, this is the highest-leverage listing available today.

5. Measure the boring things

Two numbers matter in the first week: does initialize return a valid tools/list, and do the listings that accepted you actually resolve with HTTP 200. We check every claimed listing with a script and keep the results next to the campaign notes. Links that silently 404 are worse than links you never got.

What we would do differently

Start with the registry PR, not the blog posts. The registry is read by the tooling; the blog post is read by a human who is probably not going to configure an MCP client today.

The server itself: find and verify B2B contacts over SMTP, two tools, no key needed to list them.

TAPAC is an MCP server + REST API that finds and verifies B2B contacts: npx -y @tapacapi/mcp. 100 free searches, then $0.10-0.50 per verified contact. Facts and sources cited in the article come from the product's own public docs.

DEV Community