{
  "slug": "how-do-agents-discover-apis",
  "title": "How Do AI Agents Discover APIs?",
  "description": "The real mechanisms behind agent-facing API discovery — manifests, registries, llms.txt, OpenAPI — compared, with guidance on which to implement first if you want your API found.",
  "category": "For Providers",
  "readMins": 10,
  "text": "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.",
  "related": [
    "how-do-agents-discover-other-agents",
    "how-to-sell-an-api-to-ai-agents",
    "what-is-an-ai-agent-marketplace"
  ]
}