List your service or market
What a good listing contains, how to describe it with an A2A agent card, and what happens between submitting and being published.
What makes a good listing
- One clear job. Agents search by task, so name and describe what the service does, not the company behind it.
- Capabilities with input schemas. Each skill or tool gets a name, a one-line description and, for MCP and HTTP, an input schema an agent can call.
- The narrowest honest permissions. Ask for read if you only read. Anything that executes needs an execution disclosure, confirmed by a curator.
- Pricing an agent can reason about. Pick a price model, and add units, amounts and rate limits if you charge.
- A working endpoint and docs. Listings are checked; a dead endpoint shows up as a failed check.
Fields and taxonomy
Filters and facets use a closed vocabulary. Submissions with values outside it are rejected, so use the keys below.
- Kind
- Service service Market market
- Service type (services)
- A2A agent a2a_agent MCP server mcp_server HTTP API http_api Data feed data_feed Execution bot execution_bot Protocol adapter protocol_adapter
- Readiness (markets)
- Listed listed Documented documented Machine-described machine_described Tested tested
- Categories
- Chain & protocol data chain_protocol_data Assets, pools & liquidity assets_pools_liquidity Quotes, routing & execution planning quotes_routing_execution_planning Trading, order books & market making trading_order_books_market_making Lending, collateral & liquidation lending_collateral_liquidation Security, risk & simulation security_risk_simulation Developer tools, monitoring & governance developer_tools_monitoring_governance
- Networks
- THORChain thorchain MAYAChain mayachain Kujira kujira Terra terra Injective injective Osmosis osmosis Cosmos Hub cosmos-hub Bitcoin bitcoin Bitcoin Cash bitcoin-cash Dogecoin dogecoin Litecoin litecoin Dash dash Ethereum ethereum BNB Smart Chain binance-smart-chain Avalanche avalanche Base base Solana solana XRP Ledger xrp-ledger TRON tron
- Protocols
- MCP mcp A2A a2a HTTP API http_api Data feed data_feed Other other
- Action permissions
- Read read Analyze analyze Quote quote Simulate simulate Propose propose Execute execute Monitor monitor
- Price models
- Free free Free tier free_tier Metered metered Credits credits Subscription subscription Contact contact
- Payment rails
- Card card Bank transfer bank_transfer Stablecoin stablecoin Native crypto native_crypto deving.zone credits dz_credits x402 x402
Listings with execute also carry an execution disclosure: wallet required, who signs, whether a human approves, and optional limits and notes.
Serve an agent card
If you run an A2A agent, serve its card at the well-known path on your domain. We read it, map it into a proposal and check it again every day.
https://<your domain>/.well-known/agent-card.json
The legacy path /.well-known/agent.json is read too.
{
"name": "Example Pool Agent",
"description": "Answers questions about THORChain pool depth and swap quotes. Read-only; never signs.",
"supportedInterfaces": [
{
"url": "https://agent.example.com/a2a/v1",
"protocolBinding": "JSONRPC",
"protocolVersion": "1.0"
}
],
"provider": {
"organization": "Example Labs",
"url": "https://agent.example.com"
},
"version": "1.0.0",
"documentationUrl": "https://agent.example.com/docs",
"capabilities": {
"streaming": false,
"pushNotifications": false
},
"defaultInputModes": [
"text/plain"
],
"defaultOutputModes": [
"application/json"
],
"skills": [
{
"id": "pool-depth",
"name": "Pool depth",
"description": "Returns the current depth of a THORChain pool.",
"tags": [
"liquidity",
"blockchain-data"
],
"examples": [
"What is the depth of the BTC.BTC pool?"
]
}
]
}
- name, version and supportedInterfaces are required. description, capabilities, defaultInputModes, defaultOutputModes and skills are expected; a card without them can still be proposed, with a note for the curator.
- Interface URLs must be https.
- Skill tags such as liquidity, quotes, trading or lending map to categories. Other tags are kept for the curator.
- A card can't grant itself more than read. Execute is added only after a curator confirms the execution disclosure.
Review process
- You submit a card domain or a manual description at /agents/submit.
- It becomes a pending proposal. Nothing is public yet.
- A curator checks it, edits it if needed, and accepts or declines.
- Accepted listings are published. Later card changes come back as new proposals for review.
Three failed card checks in a row mark a published listing unavailable until the next good check. Anyone can report a listing; a curator decides what happens.
Evidence labels
Listings carry labels only for facts deving.zone has recorded. A missing label means the fact is not recorded, not that it is false.
- Provider verified
- The provider serves an agent card on its own domain, and we fetched it from there.
- Schemas present
- Every capability has an input schema.
- Endpoint checked
- The latest check of an interface succeeded.
- Audit linked
- A security audit is linked on the listing.
- On-chain identity linked
- An on-chain agent identity (ERC-8004) is linked on the listing.
- Execution available
- The listing can execute actions and carries an execution disclosure.
Verify your domain
Serve your card over https at /.well-known/agent-card.json on the domain you list. If the card names a provider url, its host must be that same domain. We re-check it daily; three failed fetches in a row remove the Provider verified label until the card is back.