Skip to main content
← Back to Learn

Listed, Not Launched

Shipping a paid API and being discoverable by the agents that might buy it are different problems. This week we took our market-data tools from invisible to listed across the agent ecosystem — and learned that a directory entry is a claim, not a fact, until the live endpoint proves it.

There is a moment every product team eventually hits where the build is done and nothing happens. The API works. The pricing is honest. The docs exist. And the metrics flatline, because the people — or, increasingly, the agents — who might pay for the thing have no way to know it exists.

We hit that moment this week with our market-data tools. Corridor heat and an order-flow book, priced per call in USDC through the HTTP 402 rail, free with an API key. Technically sellable. Practically invisible.

The fix turned out to be less about marketing and more about legibility: making the product readable to the machines that do the discovering now.

The registry is the storefront

The first stop was the official MCP registry — the directory that other directories crawl. Publishing there is supposed to be a manifest upload and a signature. Ours had a worse problem: the namespace was already registered, but the signing key that authorized updates had been lost. The listing existed; the ability to maintain it did not.

Rotating a registry key is a small piece of operational hygiene with outsized consequences. Generate a new keypair, publish the public half where verifiers look for it, store the private half somewhere that survives reboots, and log in with proof-of-possession rather than password. Done carefully, the whole recovery took minutes. Done carelessly — or not at all — the storefront quietly becomes read-only forever.

With publishing restored, the manifest went up describing the remote endpoint and its payment rails. Within hours, downstream directories that ingest the registry began reflecting it. Distribution, it turns out, compounds: one canonical listing is a seed, not a destination.

Bridging the protocol gap

Not every client speaks remote MCP. Some only know how to launch a local stdio process — the Claude Desktop pattern, the npx pattern. For those, we shipped a thin bridge package: an npm-installable server that proxies every tool call to the hosted endpoint, forwarding an optional API key for free-tier access and stepping aside for pay-per-call otherwise.

The bridge is deliberately boring. It holds no business logic, stores no state, and exposes exactly the tools the remote server exposes — which is the point. When the catalog grows, the bridge grows for free. The alternative, a hand-maintained parallel implementation, would have been a second product to keep honest.

A listing is a claim

Here is the part worth remembering: every directory entry is a claim about a live system, and claims drift.

Midway through verification we noticed the live endpoint reporting fewer tools than the code we had merged. The cause was mundane — a deployment built from a stale checkout had overwritten production — but the lesson is general. A merged pull request is not a shipped feature. A published package version is not a running service. A registry entry is not a working endpoint. Each layer can lag the one below it, and the only way to know which layer you're actually looking at is to interrogate the last one: the live response itself.

So we verify at the edge. tools/list against production, counted and named. A keyless tools/call returning the expected payment challenge at the expected price. A directory's own health probe agreeing with ours. None of these checks are glamorous, and all of them are the difference between "listed" and "launched."

What this does not claim

Being listed is not being bought. The directories will crawl on their own schedules; some will pick up the listing in days, some in weeks, some never. The payment rail is live and priced, but a price is an offer, not a transaction — the first real payment is still ahead of us, and no amount of registry hygiene produces it by itself.

What changed is the shape of the problem. Yesterday the question was "does the product work?" Today it is "does anyone arrive?" Those are different questions, and confusing them is how infrastructure projects die quietly — all pipes, no pressure.

The storefront is built. The lights are on. Now we wait to see who walks in — and we check the door count ourselves, because a listing, like a quote, is only worth what it actually delivers.

Put it to work

The research above powers the product — try it or compare it: