Making an API technically discoverable (a valid manifest, a working 402 response) is necessary but not sufficient for agents to actually choose it over alternatives. This guide covers the difference between an API that's listable and one that's attractive — the things that affect whether an agent picks yours when several similar resources exist.
Pricing: fine-grained beats bundled
An agent evaluating your resource is comparing a specific price against a specific task's value, not deciding whether to "subscribe." Price per call, and price it close to your actual marginal cost plus a reasonable margin — not as a proxy for a subscription tier you wish existed. A resource priced at $0.001–$0.01 per call reads as something an agent can use liberally within a task budget; a resource priced at $5/call reads as something to avoid unless nothing else works, regardless of how good the underlying data is.
If different endpoints genuinely cost you different amounts to serve (a light lookup vs. a heavy computation), price them separately rather than averaging into one flat rate across your whole API — Agent Bazaar's own listings do this (a token price lookup at $0.001 vs. a full security report at $0.01) precisely because averaging would make the cheap calls unfairly expensive and the expensive ones unfairly cheap.
Description: write for a parser, not a pitch
An agent isn't persuaded by adjectives. It's matching your description's actual content against a task. Compare:
| Weak | Strong |
|---|---|
| "The best token security data on the market." | "On-chain risk report for a Solana token: mint/freeze authority, liquidity lock status, holder concentration and contract risk flags." |
The strong version tells an agent exactly what fields it will get back, which is what actually determines whether your resource matches a task — not superlatives. If you supply agent-first metadata (capabilities, useWhen, doNotUseWhen) in your manifest, even better: those are read and surfaced directly on your resource's page and JSON record.
Schema: document the actual output, not a sketch of it
Include a real outputSchema in your manifest entries. An agent that can validate a response against a schema before acting on it is an agent that will trust your resource enough to use it in a loop without a human checking each result — which is exactly the usage pattern that drives real call volume.
Reliability signals compound
Agent Bazaar's quality object (30-day call volume, unique payers) and verified flag exist because agents — like humans — prefer resources with a track record when several similar ones are available. There's a bootstrapping problem here (a brand-new listing has no call history yet), but the fix isn't to fake it; it's to make the resource itself good enough that early usage compounds. A resource that's fast, accurately described, and reasonably priced accumulates real usage data quickly once it's discoverable at all.
The actual listing mechanics
- Write an x402 manifest (see How to Build an x402 Endpoint for the format) with accurate descriptions, real
accepts[], and anoutputSchemaper resource. - Host it at a stable, public HTTPS URL —
/.well-known/x402.jsonis the convention. POST /submitthe URL to Agent Bazaar. No signup.- Re-submit whenever your manifest changes — it's a full refresh, not a diff, and it always takes priority over any mirrored copy from another catalog.
curl -X POST https://bazaar.saylorinnovations.com/submit \
-H "content-type: application/json" \
-d '{"manifestUrl": "https://yoursite.com/.well-known/x402.json"}'What you get in return
Payment settles directly to your own wallet — the marketplace never sits in the payment path, so there's no platform cut on the transaction itself. Discoverability is the actual value on offer: your endpoint gets found by agents that wouldn't otherwise know it exists, across every client that queries this catalog — the website, the REST API, and the MCP server alike.