Skip to main content
Glama

Sato Hub: Build Onchain & Crypto Agents

Check a recipient address before you pay it

onchain_agent_scan_recipient
Read-onlyIdempotent

USE WHEN an agent is about to pay or transfer to an address: an x402 payTo, a treasury sweep, a top-up. Pass the chain and the recipient; add the token, the origin whose 402 named the address and the paying wallet for a fuller reading. Sato Scan answers five questions, each with its own date and gap. NOT FOR checking a package, repo, token, endpoint or agent (use onchain_agent_preflight instead; its address lane wraps this reading in a wider check).

WHAT IT READS: (1) does the recipient only LOOK like an address the payer pays, matching its first and last characters without being it; (2) is the token the issuer's contract, keyed by contract address and never by symbol; (3) did the paid party declare the address, through the origin that served it or an identity that names it; (4) does the address carry a structural mark from what it did onchain; (5) is the paying wallet itself the target of address poisoning.

RULES: a reading describes what was looked at inside the stated limits, on the date given. unknown means Sato Hub holds no record either way. go means the payee was declared, the token is the issuer's contract and nothing was found within the limits: it is never a clearance. caution and no name the rule and the observed fact that decided them. A mark describes what an address did, not who controls it. The recipient, token, paying wallet, origin and amount are not stored; only the chain is. Nothing is signed or sent.

RETURNS (json): { schema: "sato.scan.recipient/v1", verdict: go | caution | no | unknown, rule, reason, answers: { token, lookalike, declared, marks, targeted }, limits, limits_text, as_of, method_version, caveat }. Read-only.

Example: { chain: "Base", to: "0x1bc0c42215582d5A085795f4baDbaC3ff36d1Bcb", token: "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", origin: "https://api.example.com/paid" }

Input Schema

NameRequiredDescriptionDefault
toYesThe recipient address the agent is about to pay: the x402 payTo, the treasury address, the top-up target.
fromNoThe paying wallet. Lets the reading compare against that wallet's own history and say whether it is being targeted by address poisoning.
chainYesChain the payment would settle on: Base, Solana, Tempo, Polygon, BNB Chain, Arbitrum, Avalanche, Optimism, Ethereum, SKALE Base, Sei, X Layer, Monad, Robinhood Chain, World Chain, Abstract.
tokenNoThe token contract (or Solana mint) the payment would use. Lets the reading say whether it is the issuer's contract. Keyed by address, never by symbol.
amountNoAmount in the token's base units. Read for context only; never stored.
originNoThe https URL whose 402 response named `to` (a public host; no credentials). Lets the reading say whether that origin declared the address.
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. Changed1 schema field changed
    • changedInput schema / properties / response_format / description
      Previous value: -"Output format: 'markdown' (default) or 'json'."New value: +"Text format; structuredContent is JSON either way."
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the read-only/idempotent/no-destruction profile, and the description adds substantial context beyond that: a privacy disclosure (recipient, token, wallet, origin and amount are not stored; only chain is), 'nothing is signed or sent', and a definition of every verdict including the crucial caveat that 'go' is never a clearance and 'unknown' means no record either way.

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 / NOT FOR / WHAT IT READS / RULES / RETURNS headers, so an agent can skim. It is on the verbose side — the five numbered questions and the rules paragraph are long — but nearly every sentence carries operational meaning, so it stops short of padding.

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?

No output schema exists, but the description inlines the full return shape (schema id, verdict enum, rule, reason, answers, limits, as_of, caveat) plus a worked example call. For a pre-payment safety check this is as complete as an agent needs to invoke 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, but the description adds genuine routing guidance: chain and recipient are the minimum, while token, origin and paying wallet are optional enrichments that widen the reading. It also explains the semantics of each optional field (what declaring an origin or comparing against the paying wallet buys you) rather than repeating schema text.

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 (scan/check) and a specific resource (a recipient address) with the exact trigger moment: 'USE WHEN an agent is about to pay or transfer to an address'. It also names the sibling it is not via 'NOT FOR checking a package, repo, token, endpoint or agent (use onchain_agent_preflight instead)', so an agent can route between the two without opening schemas.

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 ('about to pay or transfer'), a concrete list of optional inputs that deepen the reading, and an explicit exclusion list naming the alternative tool. Both the positive and negative conditions are stated, leaving nothing to inference.

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.