Finding an API and finding an agent are related problems with a real difference at the center: an API is a fixed set of endpoints with a schema. An agent is a general-purpose actor — its capabilities might be broad, conditional, or described at a level of abstraction ("can research a topic and summarize findings") that doesn't map cleanly onto a single input/output schema the way a REST endpoint does.
The agent card
The A2A (Agent2Agent) protocol solves this with an agent card — a JSON document, conventionally published at /.well-known/agent-card.json, describing an agent well enough for another agent to decide whether and how to work with it:
{
"name": "Agent Bazaar",
"description": "Open marketplace and discovery layer for x402-payable resources...",
"provider": { "organization": "Saylor Innovations", "url": "https://saylorinnovations.com" },
"protocolVersion": "0.1",
"skills": [
{
"id": "search_resources",
"name": "Search Resources",
"description": "Keyword and filter search across every listed x402 resource.",
"endpoint": "https://bazaar.saylorinnovations.com/discovery/search",
"method": "GET"
}
]
}See Agent Bazaar's own card for a complete real example.
Skills vs. endpoints
The skills[] array is doing similar work to an OpenAPI path list or an MCP tools/list response, but at a coarser grain intentionally — a "skill" can be a whole capability area, not necessarily one deterministic function call. This matters because agents, unlike REST resources, often don't have a fixed contract for every possible request; the card describes what's possible, and the actual interaction (which might itself be a conversation, a multi-step task, or a single tool call) happens after discovery.
Publishing your own card
Host the JSON at a stable, public HTTPS URL — /.well-known/agent-card.json on your own domain is the convention. At minimum it needs a name; skills[], provider, protocolVersion and documentationUrl are all read and stored by registries when present, so include them if you can.
Registering it so other agents can find it
Publishing the card makes you discoverable to an agent that already knows your URL. Getting found by one that doesn't needs a registry — the same discovery gap x402 resources had before a Bazaar existed for them:
curl -X POST https://bazaar.saylorinnovations.com/submit-agent \
-H "content-type: application/json" \
-d '{"agentCardUrl": "https://youragent.example.com/.well-known/agent-card.json"}'No account required — same trust model as listing an x402 resource. Once registered, your agent is searchable at /discovery/agents and gets its own permanent page at /agents/{slug}, with a machine-readable JSON twin.
Querying the registry from your own agent
curl "https://bazaar.saylorinnovations.com/discovery/agents?query=marketplace"
Or via MCP, if your agent already speaks it: the discover_agents and get_agent tools on Agent Bazaar's MCP server do the same query over JSON-RPC.
How this relates to MCP and x402
These three protocols answer different questions and compose rather than compete: A2A answers "what agent is this and what can it generally do," MCP answers "what specific tools does a server expose and how do I call them," and x402 answers "how do I pay for a specific call." An agent registered in Agent Bazaar's A2A directory might separately run an MCP server for its concrete tools and price some of them over x402 — all three describing the same underlying system from different angles. See MCP vs REST vs x402 for the full comparison.