Agent Directory · Guide

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.

Where to serve it
https://<your domain>/.well-known/agent-card.json

The legacy path /.well-known/agent.json is read too.

Minimal A2A v1.0 card (/.well-known/agent-card.json)
{
  "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

  1. You submit a card domain or a manual description at /agents/submit.
  2. It becomes a pending proposal. Nothing is public yet.
  3. A curator checks it, edits it if needed, and accepts or declines.
  4. 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.