Skip to main content
Glama
withgrokbot

verified-catalog

by withgrokbot
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Verified Pay-Per-Call Catalog

A static, machine-readable catalog of pay-per-call (x402) services for AI agents, with factual results of our own automated checks. Published by @WithGrokBot.

Discover (verdict-filtered index). GET https://api.402xagent.com/v1/discover?q=<terms>&verdict=pay|skip|recheck&limit=<n> searches 122,891 x402 endpoints from our Oct 20, 2026 crawl. This isn't a plain directory: every result comes with a pay, skip or recheck verdict, a skip reason, the price quoted in the endpoint's live 402 response during our crawl, the network, and an ed25519-signed receipt. Results are facts from an unpaid crawl probe, not endorsements. A pay older than 7 days comes back as recheck, so run the free check (each result's check_url, or the MCP tool endpoint_spot_check) right before you pay. Also available as the MCP tool discover at https://api.402xagent.com/mcp. — withgrokbot

Try it in one line

Which x402 web-search endpoint delivered on our last paid calls, at $0.01 or less? No key; 5 free lookups per client per UTC day:

curl -s "https://verified-catalog-lookup.withgrokbot.workers.dev/v1/lookup?task=web-search&max_price=0.01&ref=via-readme"
const r = await (await fetch("https://verified-catalog-lookup.withgrokbot.workers.dev/v1/lookup?task=web-search&max_price=0.01&ref=via-readme")).json();

Results are sorted by known-answer pass rate over our last paid calls, then price, each with its Base settlement receipts. Other tasks: /v1/tasks. Optional client=<your agent name>; ref only says where you found the link.

Related MCP server: quanta-x402-mcp

Pricing

  • 5 free lookups per client per UTC day. The client is your client value when you send one, otherwise a salted hash of your IP (raw IPs are never stored). The counter resets at 00:00 UTC. Only /v1/lookup is metered; /v1/tasks, /openapi.json and the static catalog files stay free.

  • After that, $0.02 USDC on Base per lookup via x402. The lookup answers HTTP 402 with a v2 PAYMENT-REQUIRED header (exact scheme, eip155:8453, USDC, payTo 0x37cfCC8a29e9ff9458902B29E31E42dc7B718674). Retry with a PAYMENT-SIGNATURE (or X-PAYMENT) header; the payment is verified and settled through the public PayAI x402 facilitator, and the settlement tx comes back in the PAYMENT-RESPONSE header and the response's access block.

  • Payment never changes results, sort order or listings. It buys query access only. Free, paid and exempt lookups run the same code on the same data and get identical results; no seller can pay for placement, and no check result or known-answer outcome depends on who paid. Every lookup response repeats this in payment_policy.

Remote MCP server (free)

https://verified-catalog-lookup.withgrokbot.workers.dev/mcp (Streamable HTTP, stateless JSON-RPC, no key). Same 3 tools and results as mcp/server.py: search_catalog, get_service and lookup. lookup uses the client name vc-mcp, so it shares that client's 5 free lookups per UTC day; after that it reports the 402 and does not pay. Registry name: io.github.withgrokbot/verified-catalog (server.json).

Always-paid endpoint (x402)

GET https://verified-catalog-lookup.withgrokbot.workers.dev/v1/lookup/paid?task=web-search&max_price=0.01 takes the same parameters and returns the same result as /v1/lookup, for $0.02 USDC on Base per call with no free quota. Its 402 carries x402 Bazaar discovery metadata (extensions.bazaar); it is also listed in /openapi.json (x-payment-info) and /.well-known/x402. Bad parameters get a 400 before anything is settled.

Products

Paid digital downloads sold via the same Worker over x402 (always paid; free lookup quota and SELF_CLIENTS do not apply):

  • Overnight Chief of Staff Setup Pack — $9 USDC on Base. GET https://verified-catalog-lookup.withgrokbot.workers.dev/v1/products/overnight-cos-pack (or MCP tool get_overnight_cos_pack). Unpaid calls return HTTP 402 with Bazaar discovery metadata. After payment: prompts, HTML morning-briefing template, and PDF guide.

Files

  • index.html, services/<id>.html, methodology.html: the site (no JavaScript, no requests to other hosts)

  • catalog.json, services/<id>.json, llms.txt, .well-known/agent-card.json: machine-readable

  • data/services.json: the seed listings (source and retrieval date on each), data/site.json: brand/repo settings

  • results/latest.json, results/history.jsonl, results/raw/<run>/<id>.json, results/spend_ledger.json: check results and evidence

  • scripts/run_checks.py: run checks (free/dry-run by default) and rebuild; scripts/build_site.py: rebuild only

  • data/quality_tests.json, scripts/quality.py: known-answer tests run on every paid call (pass/fail; broken services are "facts only")

  • receipts.json: every paid call (time, charged, settlement tx with Basescan link, delivered, known-answer result)

  • worker/: reliability lookup, a Cloudflare Worker (GET /v1/lookup?task=web-search&max_price=0.01&n=5) that reads catalog.json and receipts.json from this site and counts distinct clients (see worker/README.md)

  • mcp/server.py: small stdio MCP server with search_catalog, get_service (read catalog.json) and lookup (calls the Worker); the Worker serves the same tools remotely at /mcp

  • server.json: official MCP Registry entry (remote server)

  • scripts/demand_weekly.py: weekly count of distinct lookup clients -> results/demand_weekly.json

  • .github/workflows/daily.yml: daily free checks and commit

Run

python3 scripts/run_checks.py            # free checks, no payment (default)
python3 scripts/build_site.py            # rebuild pages from data/ and results/
python3 tests/run_tests.py               # acceptance tests (Node 18+ for the Worker tests)

Paid checks exist but are off by default. They need --pay, a wallet file outside this folder (--wallet), and pip install -r scripts/requirements-pay.txt. Hard caps: $0.10 per call, $1.00 per UTC day, $20.00 lifetime; only USDC "exact" on Base is ever signed.

We publish facts only, no grades. We hold no customer funds and are not a party to any seller transaction; lookup fees after the free tier go to our own wallet. To contest a result, open a GitHub issue (see methodology.html#contest).

License

MIT, see LICENSE.

Available Tools

3 tools
get_serviceA
Read-onlyIdempotent
Inspect

Fetch the complete catalog record for one known service id (e.g. from search_catalog or lookup results). Use search_catalog to find ids and lookup to rank services for a task; get_service has no per-call receipts, so for receipts with tx and Basescan links call lookup with endpoint=. Read-only. No auth or API key; free, no quota (reads the same catalog snapshot as search_catalog). Returns the record as published: id, name, provider, category, description, endpoint, advertised_price (USD, atomic, asset, network), sample_request, tasks, quality_test (known-answer test, facts_only flag and reason), paid_receipts (count), latest (full last check incl. x402_challenge, error, raw_log_url), history_summary and page_url. Unknown or missing id: error "no service with id ...".

NameRequiredDescriptionDefault
idYesExact, case-sensitive catalog service id as returned by search_catalog or lookup, e.g. "exa-search", "x402tap-weather", "onesource-erc20-balance".

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new context: no auth/API key, free with no quota, reads the same snapshot as search_catalog, and the exact error for an unknown id. It also discloses the full shape of the returned record.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and sibling routing are front-loaded in the first two sentences, and the remaining text earns its place given there is no output schema. The return-field enumeration is long and reads as a dense run-on, which slightly hurts scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully compensates by enumerating the returned fields (id, provider, category, advertised_price, quality_test, paid_receipts, latest, history_summary, page_url) and the error path. Nothing an agent needs to call or interpret this tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents case-sensitivity and gives examples, so the baseline is 3. The description adds value by pointing to where ids come from (search_catalog or lookup results) and by specifying the failure mode for an unknown/missing id, which the schema does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Fetch the complete catalog record for one known service id') and immediately distinguishes itself from siblings by naming search_catalog (find ids) and lookup (rank services / receipts). An agent can route correctly without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use routing: search_catalog to find ids, lookup to rank services, and lookup with endpoint=<id> when receipts with tx/Basescan links are needed. This is a textbook when/when-not/alternative statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookupA
Read-only
Inspect

Rank x402 endpoints for a known task at or under a price: "which endpoint should I pay for task X at <= $Y?". Prefer it over search_catalog (keyword browsing, unranked) and get_service (one id's raw record). No auth or API key. Calls the hosted lookup service as client=vc-mcp; all MCP users share that client's 5 free lookups per UTC day (reset 00:00 UTC), after which the tool returns an error reporting the HTTP 402 ($0.02 USDC on Base via x402) and never pays. Returns results sorted by known-answer pass_rate over the last n paid calls, then price, each with price_usd, pass_rate, last_check_at, last_check, stale and receipts (time, tx, basescan_url, charged_usd, delivered, quality); seller-broken services come unsorted under facts_only. No match: empty results, matched 0. Needs task or endpoint; invalid params return an error. Payment never changes results.

NameRequiredDescriptionDefault
nNoOptional. Most recent paid receipts per service used for pass_rate and returned, 1-20 (default 5; out-of-range values are clamped).
taskNoTask name from /v1/tasks, e.g. web-search, crypto-news, news, weather, token-balance, sec-filings, fx-rates, url-check. Case-insensitive; a known name matches exactly, an unknown one falls back to matching every word in service text. Required unless endpoint is given.
limitNoOptional. Maximum ranked services in results, 1-20 (default 10; clamped). facts_only is not limited.
payerNoOptional 0x wallet address (40 hex characters), recorded so a later payment from it to a returned vendor can be matched on-chain. Nothing is charged; a malformed address returns an error.
endpointNoA catalog service id (e.g. exa-search) or endpoint URL, to get one service's receipts instead of a whole task. Required unless task is given; can be combined with task.
max_price_usdNoOptional. Only services whose listed price per call is at or below this many USD, e.g. 0.01. Negative values are rejected.

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: no auth/API key needed, shared client=vc-mcp quota of 5 free lookups per UTC day with a 00:00 UTC reset, the exact failure mode afterwards (HTTP 402, $0.02 USDC on Base via x402) and the crucial guarantee that it never pays and that payment never changes results. It also discloses result ordering, staleness signaling, and the facts_only exception — rich context an agent cannot get from readOnlyHint/openWorldHint alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the ranked-question framing and the sibling routing in the first two sentences, then packs quota, output shape and edge cases densely with no filler. It is long and information-dense rather than tight prose, which costs it a point, but nearly every clause carries a fact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully carries the return-value burden: sort order (pass_rate over last n paid calls, then price), the field list (price_usd, pass_rate, last_check_at, last_check, stale, receipts with tx/basescan_url/charged_usd/delivered/quality), the facts_only case for seller-broken services, and the empty-results behavior (matched 0). Nothing an agent needs to call or interpret this tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so params like n, limit and max_price_usd are already fully documented with ranges and clamps, making 3 the baseline. The description does add one genuinely useful constraint the schema lacks (required fields list is empty): 'Needs task or endpoint; invalid params return an error.' Beyond that it adds little parameter detail the schema doesn't already carry.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (rank) and resource (x402 endpoints) plus the exact question it answers, and explicitly distinguishes itself from search_catalog (keyword browsing, unranked) and get_service (one id's raw record). An agent can select it without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives the selection condition (known task at or under a price) and names both alternatives with the reason each is worse, plus a 'prefer it over' directive. When-to-use and when-to-use-something-else are both explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_catalogA
Read-onlyIdempotent
Inspect

Browse or keyword-search the verified catalog of pay-per-call (x402) agent services. Use it when you don't know the task name or want to see what exists; use lookup to rank endpoints for a known task at a max price, and get_service for one id's full record. Read-only. No auth or API key; free, no quota or per-client limit: it only reads the catalog snapshot (bundled catalog.json in the local server, the published catalog.json on remote /mcp). Returns {count, results, generated_at, note, methodology_url}; results are in catalog order, ungraded, each with id, name, category, endpoint, advertised_price_usd, page_url and latest (checked_at, reachable, http_status, latency_ms, quoted_price_usd, price_matches_listing, charged_price_usd, delivered_valid, raw_log_url). No match: count 0, empty results. A non-numeric max_price_usd or limit returns an error.

NameRequiredDescriptionDefault
limitNoOptional. Maximum number of results, 1-100 (default 20).
queryNoOptional. Space-separated words; every word must appear (case-insensitive) in the service id, name, category, description or provider. Omit to list all. Examples: "search", "crypto news".
categoryNoOptional. Case-insensitive substring of the service category, e.g. "web search", "news", "on-chain data", "weather", "public records", "utility".
max_price_usdNoOptional. Keep services whose advertised price per call is at or below this many USD, e.g. 0.01.
reachable_onlyNoOptional (default false). If true, keep only services that were reachable in the latest check.

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the read-only/idempotent profile, but the description adds material context the annotations do not: no auth or API key, no quota or per-client limit, and the actual data source (local bundled catalog.json vs. published catalog.json on remote /mcp). It also discloses the error behavior for non-numeric max_price_usd/limit and the no-match case.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and sibling routing before the detailed return-field enumeration. The field list is long but earns most of its place because no output schema exists; still, the enumeration is denser than needed for a selection decision.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the full burden of documenting returns and does so exhaustively ({count, results, generated_at, note, methodology_url}, per-result fields, and the empty-result case), plus the auth/quota envelope. An agent has everything needed to call and interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description nonetheless adds edge-case semantics the schema omits, namely that a non-numeric max_price_usd or limit returns an error and that no match yields count 0 with empty results. It does not add syntax guidance beyond the schema examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb+resource ('Browse or keyword-search the verified catalog of pay-per-call (x402) agent services') and explicitly distinguishes itself from the siblings lookup and get_service by the condition that selects each. An agent can route correctly without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States exactly when to use it ('when you don't know the task name or want to see what exists') and names the two alternatives with their own selection conditions ('lookup to rank endpoints for a known task at a max price, and get_service for one id's full record'). Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.6.1
    • Changedget_service1 field changed
      • addedInput schema / properties / id / description
        Added value: +"Exact, case-sensitive catalog service id as returned by search_catalog or lookup, e.g. \"exa-search\", \"x402tap-weather\", \"onesource-erc20-balance\"."
    • Changedlookup9 fields changed
      • changedInput schema / properties / endpoint / description
        Previous value: -"a service id or endpoint URL instead of a task"New value: +"A catalog service id (e.g. exa-search) or endpoint URL, to get one service's receipts instead of a whole task. Required unless task is given; can be combined with task."
      • addedInput schema / properties / limit / default
        Added value: +10
      • changedInput schema / properties / limit / description
        Previous value: -"services returned (default 10)"New value: +"Optional. Maximum ranked services in results, 1-20 (default 10; clamped). facts_only is not limited."
      • changedInput schema / properties / max_price_usd / description
        Previous value: -"maximum listed price per call in USD"New value: +"Optional. Only services whose listed price per call is at or below this many USD, e.g. 0.01. Negative values are rejected."
      • addedInput schema / properties / max_price_usd / minimum
        Added value: +0
      • addedInput schema / properties / n / default
        Added value: +5
      • changedInput schema / properties / n / description
        Previous value: -"paid receipts per service (default 5)"New value: +"Optional. Most recent paid receipts per service used for pass_rate and returned, 1-20 (default 5; out-of-range values are clamped)."
      • changedInput schema / properties / payer / description
        Previous value: -"optional: your 0x wallet, so a later payment to a returned vendor can be confirmed on-chain"New value: +"Optional 0x wallet address (40 hex characters), recorded so a later payment from it to a returned vendor can be matched on-chain. Nothing is charged; a malformed address returns an error."
      • changedInput schema / properties / task / description
        Previous value: -"task name, e.g. web-search, crypto-news, weather, token-balance"New value: +"Task name from /v1/tasks, e.g. web-search, crypto-news, news, weather, token-balance, sec-filings, fx-rates, url-check. Case-insensitive; a known name matches exactly, an unknown one falls back to matching every word in service text. Required unless endpoint is given."
    • Changedsearch_catalog8 fields changed
      • addedInput schema / properties / category / description
        Added value: +"Optional. Case-insensitive substring of the service category, e.g. \"web search\", \"news\", \"on-chain data\", \"weather\", \"public records\", \"utility\"."
      • addedInput schema / properties / limit / default
        Added value: +20
      • addedInput schema / properties / limit / description
        Added value: +"Optional. Maximum number of results, 1-100 (default 20)."
      • changedInput schema / properties / max_price_usd / description
        Previous value: -"maximum advertised price per call in USD"New value: +"Optional. Keep services whose advertised price per call is at or below this many USD, e.g. 0.01."
      • addedInput schema / properties / max_price_usd / minimum
        Added value: +0
      • changedInput schema / properties / query / description
        Previous value: -"words to match in name, category, description"New value: +"Optional. Space-separated words; every word must appear (case-insensitive) in the service id, name, category, description or provider. Omit to list all. Examples: \"search\", \"crypto news\"."
      • addedInput schema / properties / reachable_only / default
        Added value: +false
      • changedInput schema / properties / reachable_only / description
        Previous value: -"only services reachable in the latest check"New value: +"Optional (default false). If true, keep only services that were reachable in the latest check."
  2. 3 tool updatesv0.1.0
    • First observedget_service
    • First observedlookup
    • First observedsearch_catalog
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.6/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct role: search_catalog browses or keyword-searches, get_service fetches one full record by id, and lookup ranks endpoints for a known task and price. Their descriptions explicitly state when to prefer each over the others, leaving no meaningful ambiguity.

Naming Consistency4/5

The names are consistently snake_case and mostly follow a verb_noun pattern (search_catalog, get_service), but lookup is a bare verb. This is a minor deviation rather than an inconsistent convention.

Tool Count5/5

Three tools is well-scoped for a read-only catalog server: one for browsing/search, one for detail retrieval, and one for ranked task-specific lookup. Each earns its place without redundancy.

Completeness4/5

The surface covers discovery, ranking, and detail retrieval for the catalog, which is appropriate for a read-only service. Minor gaps exist, such as no dedicated category/task listing tool, but agents can work around this via search_catalog.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers