We shipped endpoint 244 last week. Nobody's going to read all of them.

That's the real discovery problem in x402. The Coinbase Bazaar shows a flat list. Most MCP catalogs do the same. An agent looking for "is this cert chain valid" gets the same surface as one looking for "what time is sunset in Lagos." The signal is buried.

So we tag everything.

How the tag system works

Every endpoint in the agentutility registry carries 3 to 7 tags. They live in a single field, lowercase, no spaces. They aren't free-form: there's a controlled vocabulary of around 60 tags, audited weekly when new endpoints land.

Tags describe what an endpoint does. The cluster is the org chart. Tags are the index.

A few worked examples.

security returns 38 endpoints across two clusters. Prooflayer contributes secrets-exposure-check, certificate-transparency-lookup, vuln-cve-fetch, and auth-header-audit. WebProbe contributes tls-version-check, mixed-content-scan, csp-header-parse, and hsts-policy-fetch. Different teams, different upstream sources. Same question being asked by the agent: "is this thing safe."

civic returns 11 endpoints, all in Locale. polling-place-lookup, legislator-by-zip, voter-registration-deadline-by-state, that family. A travel agent doesn't need any of them. A civic-tech agent doesn't need timezone math. Tags split the cluster.

pricing returns endpoints from two clusters: Bazaar Intel for x402 endpoint pricing data, and Satellite Tile for sat imagery quote endpoints. Useful when an agent needs to figure out what something should cost before it pays.

Composing tags with clusters

You can grep by tag alone. Or you can compose.

tag=security cluster=prooflayer is 24 endpoints. The Prooflayer-specific security surface, without the WebProbe overlap.

tag=security NOT cluster=prooflayer is 14. The "everywhere else we touch security" surface, mostly WebProbe.

tag=identity tag=onchain is 6. The intersection. ens-resolve, erc-8004-agent-lookup, farcaster-fid-from-address, wallet-label-lookup. Agent identity is its own little sub-portfolio if you slice it that way.

The /endpoints.txt format

JSON is fine for code. It's bad for grep.

So we publish https://agentutility.ai/endpoints.txt alongside the JSON registry. One endpoint per line, pipe-delimited: 

slug | cluster | price-usdc | tags-comma-separated | one-line-purpose

An agent or a human can run: 

curl -s https://agentutility.ai/endpoints.txt | grep security

That returns 38 lines, each grep-able for whatever the next filter is. No JSON parsing, no pagination, no API key. It's a flat file that updates every time the registry does.

The same data lives at /endpoints.json if you want structure. But the .txt version is the one we see hit most from agent traffic. Probably because shell pipelines compose better than HTTP clients.

Why this matters for routing

Most agent frameworks pick endpoints by reading the description field and embedding it. That works when there are 10 endpoints. It breaks at 244 because the descriptions all start to look like vector neighbors.

Tags short-circuit the embedding step. If the agent's planner already knows it needs security plus onchain, it can prune the search space to 4 endpoints before any LLM call fires. The router gets faster and cheaper. The wrong endpoint gets called less often.

And the controlled vocabulary matters. If half the security endpoints were tagged security and the other half infosec, the grep would split and the agent would miss results. So we lint tags on every registry merge: any new tag that isn't in the vocabulary list fails the build until someone either renames it or adds it intentionally.

That's the whole pitch. We tag, we publish a flat-file index. Agents do less work.