Twenty-four searches, twelve answers: what our own catalog search measures

A marketplace usually answers "can a buyer find what they need?" with a supply number: we have N endpoints. That number says nothing about the query an agent actually types. We took 24 real search terms from a public 30-day demand preview, ran each one verbatim against our own catalog, and counted what came back. Twelve answered. Every one of the five zeros was the same missing capability.

The measurement is boring and reproducible, which is the point: one GET per term, a hit count, and a reading of why. No sampling, no survey.

1. How our search actually matches

Our catalog search is a literal token AND. A query is split into tokens, and a row matches only if every token appears in its description (or name). There is no stemming, no synonym table, and no relevance ranking to hide behind. So:

• weather matches anything whose description says weather.
• stock research matches only rows carrying both words — stock in one sentence and research in another is enough, but a row that only says "quote" does not match research.
• daily stock screen matches nothing unless daily, screen and stock all appear. A buyer's phrasing is not a superset of our vocabulary; it is a different vocabulary.

That makes the description a query surface, not marketing copy. It is also why "just add more listings" does not move these numbers: a new row with a one-line description adds one more row that a multi-word phrase still misses.

2. What the 24 terms returned

Terms are deduplicated from the preview; counts are searches and distinct client IPs over 30 days. Hit counts were measured on 2026-11-15 against the live catalog.

Three rows are omitted for length — scriptmasterlabs, beacon and scalpstream — all seller names, all zero hits.

3. Seven of them are not demand at all

Seven terms are seller names — one word, no verb, no object. saymon, ukintel, klearflow, kristo, scriptmasterlabs, scalpstream and beacon account for 217 searches across 34 IPs. Someone is looking for a named seller. Our returning zero is a listing question, not a coverage question, and counting it as missed demand would push us to add endpoints nobody asked for.

4. Twelve of the seventeen capability terms answer

Stripping the name lookups leaves 17 terms that describe a capability. Twelve return at least one service today, including the three that returned zero the day before. Those three were closed by rewriting descriptions to state what the handler already does:

• csv preflight — the handler parsed CSV but never validated it, so the description could not honestly say "preflight". We added a validator that returns {rows, issues} and documented it; the existing parse path was rewritten to delegate to it, with 200,010 random inputs compared byte-for-byte before deploy.
• check an x402 endpoint before paying it and x402 payment endpoint test — the services did exactly this, but their descriptions never used the buyer's words. Token matching is literal (pay does not match paying), so the words had to be in the description.

None of those three was a new endpoint. Each was a case of the capability existing and the description not saying it.

5. The zeros that are not a wording problem

All five remaining zeros are one family:

95 searches across 15 distinct client IPs in 30 days, all asking the same thing: rank or compare many tickers. Our nearest endpoint takes one symbol and returns a quote plus a price-derived research snapshot — 52-week range, trailing returns, moving averages, volatility. It cannot screen a universe, and no description rewrite changes that. Writing "screen" into its text would have produced a hit and a misleading answer; the query is not the product.

So the honest state of this catalog is: description work is exhausted for this demand list, and the next increment is a capability. That is a much more useful sentence to have written down than "we have 1,894 endpoints".

6. What a marketplace should publish about its own search

Three things, all cheap:

1. The exact matching rule. "Token AND, literal, no stemming" is a sentence a buyer can act on. "Smart search" is not. We document ours in AGENTS.md.
2. The query surface is the description. If the description cannot state a capability, the capability should not be advertised — and if the description omits the words buyers use, the capability is invisible. Both failures are silent unless someone runs the demand terms.
3. Stop-word filtering is not a fix for this. Dropping the and of helps phrases like how do i validate an email domain, where the meaningful words all exist. It does nothing when the missing token is screen. We have that filtering written and measured as a patch, and it is deliberately not deployed: it keeps the AND semantics (an extra word still filters), filters before the 16-token cap, and falls back to the original tokens when a query is all stop words. Shipping it changes no zero in the table above.

None of this is specific to us. Any directory whose search is token-based and whose rows are described in one sentence will show the same split: a few phrases that describe what exists, and a long tail that describes what does not. The difference between the two is worth measuring before writing the next listing.

minia2a is a pay-per-call market for x402 endpoints, priced in USDC on Base with five free trial calls per signed wallet. The numbers above come from running its catalog search, not from a survey.