Skip to main content
Glama

Sato Hub: Build Onchain & Crypto Agents

Find a paid x402 service for a need, ranked by observed evidence

onchain_agent_find_x402_service
Read-onlyIdempotent

USE WHEN an agent needs a paid API or data service it can call and pay per request with x402, and wants the ones with evidence behind them first. Find a paid API/data service an agent can call and pay per request with x402: market data, onchain data, web data, search, inference, security checks, identity lookups, dev tools and more. Describe the need in plain words; optional category, chain and max_price_usd narrow it.

RULE ENFORCED: results are ranked by what Sato Hub observed, never by what a seller says about itself and never by anything paid to us. Order: (1) x402-style payments to the payout address on Base in the last seven days from several outside payers, not machine noise (counted when the transaction carries a signed USDC authorization, EIP-3009, the settlement x402's exact scheme uses; some non-x402 gasless sends use it too); (2) the listed URL answered HTTP 402 with a payment payload when we asked; (3) everything else, unknown before no. All USDC received at a payout address is context only and never ranks. Ties go to the lower per-call price. Each hit carries both readings with their dates and method, and links to the one canonical page for its payout address. unknown means we hold no reading, never that the service failed. A price is what the seller registered, not a charge we observed; price_usd appears only where the asset is USDC on Base or Solana. A hit is a description of what was observed, not an endorsement, and nothing here pays for or calls a service.

NO HIT IS INVENTED: when nothing matches, the answer says so and names how to broaden (fewer words, drop a filter, another category).

Returns (json): { hits: [{ url, network, chain, description, category, price_usd, merchant: { slug, display_host, pay_to, answers_402, payments, claimed_at, is_ours }, sato_url }], matched, capped, match_mode, evidence_as_of, ranking, guidance, unavailable }. merchant.payments carries the x402-style reading (the x402_* fields, which rank) and, as context only, the all-USDC reading. sato_url is the canonical page for the payout address. Read-only.

Example: { need: "token prices", chain: "Base", max_price_usd: 0.01 }

Input Schema

NameRequiredDescriptionDefault
needYesWhat the service should do, in plain words, e.g. 'token prices for ETH' or 'scrape a web page to text'. Matched against the listing text, host and URL.
chainNoNarrow to a chain by name, e.g. Base or Solana.
limitNoHits to return (1-20, default 10).
categoryNoNarrow to one category: market-data, onchain-data, web-data, search, inference, media, security, identity, dev-tools, commerce, agents, other.
max_price_usdNoPer-call price ceiling in USD. Listings with no decodable per-call price are left out when this is set.
response_formatNoText format; structuredContent is JSON either way.markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent safety, but the description goes well beyond them: the exact ranking order, what 'unknown' means, that price is seller-registered rather than observed, that nothing is an endorsement, and that no hit is invented. This is unusually rich behavioral disclosure.

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 USE WHEN, then the ranking rule, returns, and an example — a sensible order. The RULE ENFORCED block is verbose and partly restates itself ('not an endorsement' / 'never by what a seller says'), but nearly every sentence carries distinct information.

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?

For a ranking/semantics-heavy tool with no output schema, the description documents the return shape, the evidence fields, tie-breaking, and failure modes, which is everything an agent needs to call it correctly.

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 the baseline is 3. The description mentions that need is plain words and that category/chain/max_price_usd narrow results, but adds little syntax or meaning beyond the schema's own per-parameter descriptions.

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 ('find') and resource ('paid x402 service') plus the ranking dimension ('ranked by observed evidence'), and the domain is tight enough to separate it from siblings like search_listings or search_resources.

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

Usage Guidelines4/5

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

'USE WHEN an agent needs a paid API or data service it can call and pay per request with x402' gives an explicit trigger condition, and the no-hit guidance ('fewer words, drop a filter, another category') tells the agent how to recover. It does not, however, name a sibling alternative for when this tool is the wrong ranking model.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.