Stablecoin Scanner

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds behavior beyond them: heavy read that can return 'busy or timeout' under load with retry-with-backoff guidance, no auth, and a 1200 req/min shared rate limit. It also discloses the interpretive caveat that the band is a heuristic over decoded Approval facts, not an AML/legal determination.

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

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

Front-loaded with the purpose before the exclusions and operational caveats, and every clause carries signal. It is dense and long, but the sentences are load-bearing rather than padding, so it stops short of a 5 only because of sheer density.

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

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 contract: one row per spender/token, raw value, unlimited/oversized/old flags, spender_class, and the band vocabulary (critical|high|low|expired|none). It also documents failure modes and rate limits, so 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.

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 meaningfully exceeds it by clarifying that 'address is the allowance owner (the granter), never the spender' — a semantic distinction the schema's generic 'The address to check' does not convey, and one that materially affects correct invocation.

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

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

States a specific verb+resource with scope: 'Open ERC-20 and Permit2 allowances one address has granted on one chain, one row per spender and token.' It also enumerates the returned fields (raw value, flags, spender_class, band), so the agent knows exactly what this produces and how it differs from the risk/compliance/exposure siblings.

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

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

Explicit when-to-use ('what a wallet has approved and who could pull its stablecoins') plus three explicit when-NOT clauses routing to named alternatives: not for risk tier (get_address_risk), not for issuer freezes (get_address_compliance), not for taint (get_address_exposure). 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.

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

Annotations cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds substantial context beyond them: no auth, a 1200 req/min shared rate limit, heavy-read behavior that can return busy/timeout, and the critical interpretation caveat that 'unknown' and empty arrays mean 'not fully backfilled' rather than clean. It also scopes the tool away from being an identity, AML, or legal determination.

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

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

Purpose is correctly front-loaded, but the body is a single sprawling paragraph with stacked parentheticals and embedded caveats, making it hard to scan. Most content earns its place, yet readability suffers from the lack of sentence breaks or bulleted structure for the four result arrays and the four sibling exclusions.

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

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 return-value burden and does so thoroughly: it names the four arrays and their per-row semantics, explains status values, and clarifies response fields like chain_id, chain_source, and chains_with_data. Caveats about backfill gaps and cross-chain freeze sharing close the remaining interpretation risk.

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

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

Schema coverage is 100% and the schema descriptions already document chain spellings, defaults, and address respelling, so baseline is 3. The description adds genuinely new semantic guidance not in the schema: that each chain is a separate issuer act, that the caller should re-query with chain set, and that chains_with_data reveals where else the address has data.

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

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

Opens with a specific verb+resource+scope: 'Issuer freeze/seize facts for one address on one chain, plus the OFAC SDN flag,' then enumerates the exact result sections (freeze[], not_freezable[], frozen_elsewhere[], freeze_proposals[]). It explicitly disambiguates from three named siblings (get_address_risk, get_address_exposure, get_sanctions_status), so an agent can route correctly without opening any other definition.

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

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

Gives a positive trigger ('Use it when the question is whether an issuer or OFAC acted on this address, or how much is frozen') and three explicit exclusions with the correct alternative named for each. It also adds operational guidance (retry with backoff under load) and a workflow instruction to read chains_with_data before concluding.

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

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

Beyond the readOnly/idempotent/openWorld annotations, it discloses cache reuse (60 s, 10 s after time_budget), heavy-read behavior (busy/timeout under load, retry with backoff), auth (none) and rate limit (1200/min shared). It also explains what 'unknown' means and that it is never a false 'none', plus the fixed 3-hop depth and no cross-chain walking.

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

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

Purpose is front-loaded and the alternative-routing follows immediately, so structure is strong. The text is very dense and long, but each clause (caching, unknown semantics, rate limit, chain re-ask) carries distinct information rather than repetition.

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

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 burden: it explains the answer classes, the unknown/degraded-state taxonomy, incomplete_reasons, caching, retry, and multi-chain handling. Nothing needed to invoke or interpret the result is missing.

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

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

Schema coverage is 100% and the schema descriptions are already exhaustive, so the baseline is 3. The description adds value by stating the fixed 3-hop depth, the no-cross-chain rule, and the directive to consult chain_id/chains_with_data and re-ask per network — semantics beyond the raw field docs.

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

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

States a precise verb and resource ('Taint exposure of one address on one chain') and defines the mechanism ('bounded backward walk over the value graph to the nearest OFAC-sanctioned or hack/drainer/mixer root') and the answer shape (class, nearest hop, haircut fraction). It explicitly differentiates from siblings, so an agent can place it without opening a schema.

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

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

Gives explicit when-not conditions and names the correct alternative for each: get_address_risk for a go/no-go tier, get_wallet_graph_walk for counterparties/depth/token/window, get_address_compliance for issuer freezes. Nothing about routing 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.

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

Annotations already mark this as a safe read-only, idempotent operation, and the description adds substantial context: what 'unknown' means, how freeze input affects the tier, the Solana freeze-pair caveat, fixed 3-hop exposure, 60s/10s verdict reuse, busy/timeout retry behavior, no auth, and a shared 1200 requests/min limit. There is no contradiction with the annotations.

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

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

The description is front-loaded with purpose and alternatives, and most sentences carry operational constraints an agent needs. However, the single dense paragraph with nested parentheticals and deep edge-case detail is heavier than necessary for maximal conciseness.

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

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

There is no output schema, but the description covers tier values, evidence and incomplete_reasons, unknown semantics, caching, failure modes, and safety/legal limits, while the schema fully covers the inputs. This is complete enough for correct invocation of a complex risk read.

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

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

Schema description coverage is 100%, so both address and chain are already fully documented in the schema. The description does not add syntax or format guidance for those parameters beyond high-level phrasing, so the baseline of 3 applies.

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

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

The description states the exact resource (one address on one chain) and the returned artifact (a unified risk tier with enumerated values), then distinguishes it from the compliance, exposure, and approvals siblings. An agent can identify the tool without opening its schema.

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

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

It explicitly says to use this for a go/no-go read before accepting or sending funds, and names when not to use it with the exact sibling alternatives for freeze/compliance, taint/exposure, and allowances/approvals. It also routes depth and window selection to get_wallet_graph_walk.

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

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

Goes well beyond the annotations (readOnly/idempotent/openWorld) by disclosing operational behavior: heavy read that can return busy or timeout under load with a retry-with-backoff recommendation, no auth, and a 1200 requests/min shared rate limit. It also specifies the returned row shape, including finality and conditional usd_amount.

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

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

Purpose and scope are front-loaded and every clause carries real information (sibling exclusions, pagination mechanics, output fields, limits). It is dense and long, but not padded; the length is largely justified by the breadth of behavior it must convey without an output schema.

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

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

With no output schema, the description supplies the answer shape (items[] with tx_hash, log_index, block_number, block_time, payer, recipient, amount, token, finality, usd_amount) plus pagination, auth, and rate-limit context. An agent has everything needed to call and interpret this tool correctly.

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

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 semantic value: payer and recipient narrow together (AND), omitting both yields the chain-wide feed, and a page lacking next_cursor is the last. That refines the terse schema text for cursor and the payer/recipient relationship.

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

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

States a specific verb+resource with scope: 'Recent stablecoin transfers on one chain, newest first, filterable by payer and/or recipient, cursor-paginated.' It explicitly names what it is not (get_wallet_graph_walk, get_sync_status, get_address_risk), so an agent can separate it from every relevant sibling without opening a schema.

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

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

Gives explicit when-to-use ('latest transfers of an address or of the whole chain') and three named alternatives with the condition that selects each ('Not for who an address settles with over time: get_wallet_graph_walk', etc.). 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.

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

Beyond the readOnly/idempotent/openWorld annotations, it discloses auth posture (no auth), a shared rate limit (1200 req/min across all tools), latency behavior ('never waits for a slot'), and a state edge case (updated_at null until first ingest). It also flags data provenance and a caution to verify against the official SDN list.

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

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

Front-loaded with the returned payload before use cases and exclusions, and nearly every sentence carries routing or behavioral information. The closing verification/legal disclaimer is defensible for sanctions data but adds length without helping invocation.

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

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 describing the return payload (per-chain counts, total, updated_at semantics, source), and it does so. Combined with the no-auth/rate-limit notes, an agent has everything needed to call and interpret this tool.

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

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

Zero parameters, so the baseline is 4. The description confirms the no-argument design and that one answer covers every chain, which is a useful signal, but there is no additional parameter meaning to convey.

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

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

States a specific verb+resource: it reports the OFAC SDN list coverage as the scanner holds it, enumerating the exact fields returned (evm_count, solana_count, tron_count, total, updated_at, source). It explicitly separates itself from get_address_compliance and get_address_risk, so an agent can distinguish it from siblings without opening a schema.

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

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

Gives positive triggers ('date the sanctions input behind a verdict', 'tell a clear OFAC flag from an unloaded list') and explicit negative routing to three named alternatives (get_address_compliance, get_address_risk, get_sync_status) with the condition that selects each.

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

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

Annotations cover the safety profile, and the description layers on real behavioral context: null freshness when unreadable, lag_blocks formula, negative lag meaning the node head regressed, Solana's degenerate lag semantics, 'never waits for a slot', no auth, and a 1200 req/min shared rate limit.

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

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

Front-loaded with the purpose and key return fields, and nearly every clause carries distinct information. It is dense and slightly long due to the Solana and lag caveats, but those caveats prevent misreading, so the length is largely earned.

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

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 and does so: it names each returned field, explains nullability and the lag formula, and covers auth, rate limits, and chain-specific semantics. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100% and the schema already documents every accepted spelling and the Base default, so the description's 'chain is the only parameter; omit it for Base' largely restates structured data. Baseline 3 is appropriate; the description adds no syntax beyond the schema.

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

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

Opens with a specific verb+resource ('Indexer freshness for one chain') and enumerates exactly what is returned (freshness_seconds, head/finalized blocks, safe block, lag_blocks). It explicitly distinguishes itself from the sibling get_sanctions_status and clarifies scope against address answers.

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

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

Gives explicit when-to-use ('before trusting how recent an address answer is, or to tell an empty feed from a stalled indexer'), when-not-to ('Not for how fresh the OFAC list is: get_sanctions_status'), and even a de-prioritization rule ('call this only for the block numbers or for a chain you have not asked about yet').

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description still adds substantial behavior: heavy-read load behavior with retry/backoff guidance, the ~50k degree gate returning hop 1 with frontier_truncated, the 1200 req/min shared limit, no-auth, and the window_from edge-grain horizon caveat. Solana-specific coverage_status semantics (pending/partial/unreadable) and the incomplete 2026-07-20..2026-09-14 grain are disclosed with concrete interpretation rules.

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

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

The purpose and alternative-routing sentences are front-loaded, but the body is an unusually long, dense wall of mixed caveats (rate limits, Solana coverage, the 2026-09 grain incident) that is hard to scan and repeats horizon/absence reasoning. Much of it earns its place for an explainability primitive, but the overall shape is bloated relative to its size budget.

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

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

No output schema exists, and the description compensates thoroughly by explaining returned fields and their meaning (window_from horizon, volume in raw minor units vs volume_usd6, chain_id/chain_source/chains_with_data, coverage_status). For a complex, ambiguous read it leaves nothing an agent needs to interpret the result unstated.

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

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

Schema description coverage is 100%, so the baseline would be 3; the description nevertheless adds interpretable meaning beyond the schema — token must be a chain-enabled stablecoin or a refusal names the alternatives, hops=0 as the cheapest self-check, and window_from as the reportable horizon rather than the requested window start. Some parameters (stop_at_attributed, frontier_cap tuning) get limited added semantics, keeping it short of a 5.

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

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

Opens with a specific verb and resource ('Bounded walk over the indexed settlement graph of one stablecoin from one wallet on one chain') and enumerates the exact graph semantics (payer<->recipient hops, value-weighted scores, entity-aware node keys, stop conditions). It names the sibling tools it is not, so an agent can distinguish it from get_address_risk, get_address_exposure and get_recent_transactions without opening their schemas.

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

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

Explicit when-to-use ('explain who an address settles with and through which hops') plus three named exclusions with the alternative for each, and it points to the cheapest invocation ('hops=0 with stop_on_sanctioned=true'). It also states preconditions (token required and must be an enabled stablecoin) and the failure mode for violating them.

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