Tool marketplace

Beyond the routed categories (search, scrape, image, and so on), Route Tools exposes a flat marketplace of individually addressable tools: social data, SEO and traffic intelligence, on-chain analytics, person and company enrichment, media generation, and more. Every tool is called direct against its upstream and billed per call from the same prepaid balance and the same rt_live_ API key.

There are 1,658 tools across 26 providers. Rather than register every one as its own endpoint, the marketplace is driven by three verbs.

Discover

curl -H "Authorization: Bearer $RT_KEY" \
  "https://api.route.tools/v1/marketplace?q=instagram&group=social&limit=10"

Query parameters: q (keyword over id, name, path, provider, group), provider, group, tag, available (only tools routable on this deployment), limit, cursor. Groups are social, seo, web, crypto, enrichment, media, comms, weather, news, browser, and files. List providers with GET /v1/marketplace/providers.

Discovery is authenticated but never requires a positive balance, so an agent can browse the catalog before it has credits.

Inspect

curl -H "Authorization: Bearer $RT_KEY" \
  "https://api.route.tools/v1/marketplace/tikhub__api_v1_instagram_v2_fetch_user_info"

Returns the method, path, price, pricing model, auth style, and whether the tool is currently routable.

Run

curl -X POST -H "Authorization: Bearer $RT_KEY" -H "Content-Type: application/json" \
  -d '{"input": {"username": "nasa"}}' \
  "https://api.route.tools/v1/marketplace/tikhub__api_v1_instagram_v2_fetch_user_info/run"

input is a free-form object. Any {placeholder} in the tool path is filled from it; the remaining fields become the query string (GET) or the JSON body (POST). Pass method to override the default verb and include_raw: true to also receive the upstream’s unmodified payload. The call is billed per call (or per result) at the tool’s listed price, debited post-hoc from your balance.

Pricing

Each tool lists a fixed price_usd. Prices are set below the prevailing market reference for the same upstream, so routing through Route Tools is cheaper than wiring each provider up yourself, with one balance instead of 26 invoices.

Availability and rollout

Execution is enabled provider by provider as each upstream’s base URL, authentication, and request shape are validated. A tool that is catalogued but not yet routable reports coming_soon: true and returns 503 unavailable from /run; discovery and inspection still work. A live tool also needs its credentials configured on the deployment: an API key for key-based providers, or the platform wallet for x402 providers.

x402 payments

On-chain providers do not use an API key. They answer a bare request with 402 Payment Required and a list of payment options; Route Tools signs a gasless USDC authorization (EIP-3009) and retries, settling per call. This is handled inside the executor, so an agent calls these tools exactly like any other and sees the settlement on the response:

{
  "result": { "...": "..." },
  "usage": { "price": 0.093, "latency_ms": 1840, "units": 1 },
  "payment": { "network": "base", "amount_usd": 0.11, "transaction": "0x..." }
}

Guardrails: the platform wallet key (X402_WALLET_KEY) must be configured, settlement is restricted to an allowed EVM network list (X402_NETWORKS, default base) and to USDC via the “exact” scheme, and every call is capped (X402_MAX_USDC_PER_CALL, default $5). A payment is only ever produced in response to a valid 402 challenge, so a wrong path simply errors and spends nothing. Non-EVM options (for example Solana RPC) are declined until a matching scheme is added.

MCP

The same three verbs are exposed to MCP clients as discover_tools, inspect_tool, and run_tool, alongside the routed category tools. An agent discovers a tool, inspects it, then runs it, without the marketplace ever flooding the client’s tool list.