An agent can't discover an API by stumbling onto a landing page the way a human might via search or word of mouth. It needs a mechanism built for machines to query. In practice there are a handful of real, distinct mechanisms in active use today — this guide covers what each one actually is, not just that it "exists."
1. Registry / marketplace discovery
A centralized (or federated) catalog an agent can search — this is what Agent Bazaar is. The agent doesn't need to know your API exists ahead of time; it queries the registry with intent ("I need Solana token risk data") and the registry returns matching, priced, schema-documented resources:
curl "https://bazaar.saylorinnovations.com/discovery/search?query=solana+token+risk"
Getting listed: POST /submit with your x402 manifest URL. No account, no approval queue.
2. x402 manifests (self-hosted discoverability)
A JSON document at a conventional path on your own domain (commonly /.well-known/x402.json) listing your paid resources with their accepts[]. This is the format registries like Agent Bazaar and Coinbase's CDP Bazaar actually crawl and mirror — publishing one is simultaneously self-hosted discoverability and your ticket into every registry that indexes manifests. See How to Build an x402 Endpoint for the format.
3. llms.txt
A plain-text file at /llms.txt on your domain, written for an LLM to read directly — a concise summary of what your site/API offers and links to the machine-readable specifics (your OpenAPI doc, your manifest). Not a formal protocol with required fields, more a convention that's become common enough that agents and LLM-integrated tools increasingly check for it by default. Agent Bazaar's own is at /llms.txt (and a longer version at /llms-full.txt).
4. OpenAPI documents
The long-established format for describing REST APIs — paths, parameters, response schemas. Not agent-specific (it predates the current wave of agent tooling by a decade), but widely supported by agent frameworks that can import an OpenAPI spec and generate callable tools from it automatically. If you already maintain one, you're most of the way to agent-discoverable without extra work; see Agent Bazaar's own at /openapi.json for the shape.
5. MCP tool listings
If you run an MCP server, tools/list is itself a discovery mechanism — any MCP client connected to your server immediately sees what you offer. This only helps agents that already know to connect to your specific server, though, which is a narrower form of discovery than a registry an agent can search without prior knowledge of you. See What Is MCP?.
Comparing them
| Mechanism | Agent needs to know about you first? | Includes pricing? | Effort to implement |
|---|---|---|---|
| Registry/marketplace | No — that's the point | Yes, if listed with a manifest | Low (submit a URL) |
| x402 manifest | No, if a registry crawls it | Yes | Low-medium |
| llms.txt | Only if it already found your domain | No (usually links out) | Low |
| OpenAPI doc | Only if it already found your domain | No | Medium (if not already maintained) |
| MCP tools/list | Yes — has to know your MCP server URL | No | Medium |
What to actually implement, in order
If you're starting from zero: write an x402 manifest first (it's the one artifact that gets you both self-hosted discoverability and eligibility for registry mirroring), submit it to Agent Bazaar and any other registry you care about, then add llms.txt (cheap, broad benefit) and an OpenAPI doc if you don't already have one. MCP is worth building once you have an established set of tools worth exposing that way — it's additive, not a replacement for the manifest.