Supply
Discovery
Everything an agent needs to find and pay for a capability is published in standard formats. None of it describes how Tollex is built.
Documents a Tollex service publishes
| Path | Format | Contents |
|---|---|---|
/.well-known/tollex.json | JSON | Identity, payment terms (networks, assets, schemes) and every entry point. |
/openapi.json | OpenAPI 3.1 | The planning API and every paid route, with pricing in x-tollex-pricing. |
/llms.txt | Text | A short orientation for model-driven agents. |
/.well-known/agent-card.json | A2A 1.0 agent card | One skill per capability, the JSON-RPC interface and the x402 extension. |
/.well-known/mcp/server-card.json | MCP server card (draft) | Published only when an MCP endpoint is configured. |
/.well-known/tollex-receipt-keys | JSON | Receipt signing keys, with rotation and revocation status. |
x402 Bazaar
Every 402 response carries resource.serviceName (“Tollex”), short tags and the Bazaar discovery extension: the HTTP method, an example input, the input schema and the output schema. Facilitators that run a Bazaar catalogue can list these resources automatically when payments pass through them. Tollex validates each declaration before publishing it and leaves it out rather than publish one that does not validate.
A2A
The agent card lists a JSON-RPC interface at /a2a. Version 1.0 (SendMessage) and 0.3 (message/send) are both accepted, negotiated by the A2A-Version header. Send a data part { toolId, input }. An unpaid call returns a task waiting for input, with the x402 terms in x402.payment.required; resend with x402.payment.payload to pay. The same paywall, receipts and success-only billing apply.
MCP
The Tollex MCP server exposes five tools by default: tollex_resolve, tollex_do, tollex_operation, tollex_verify_receipt and tollex_discover. An operator can opt into a full mode that also lists every capability as its own tool. It runs over stdio or Streamable HTTP. Provider descriptions are sanitised and flagged when they look like instructions. See MCP server.
What Tollex discovers
Tollex also reads other people’s catalogues: x402 Bazaar listings from facilitators, MCP servers and A2A agents. It probes each resource for live payment terms before trusting a listing, through the same guarded fetch used for providers.
External x402 resources whose live terms were verified enter the capability model with origin EXTERNAL_X402. They are evaluated under the same constraints, only when a request sets includeExternal. Where the operator enables external execution, the agent’s wallet pays the merchant directly after the live 402 is checked against the plan, and Tollex adds no fee; otherwise buying one returns EXTERNAL_EXECUTION_NOT_CONFIGURED before anything is signed. They carry no Tollex execution receipt; Tollex signs route evidence instead. See External x402 merchants.
Compatible agents can discover and use Tollex automatically when their runtime supports the relevant discovery and payment protocols. Other agents can be pointed at /.well-known/tollex.json.