Stablecoin Scanner

get_address_risk

Read-onlyIdempotent

Unified risk tier for one address on one chain — unknown|none|low|medium|high|severe — from decoded facts (OFAC listing, issuer freeze/seize on this chain, exposure to a sanctioned or hack root) and attributed labels with provenance (labels alone cap at medium; a lone-source accusation adds no tier). Use it for one go/no-go read before accepting or sending funds. Not for freeze proposals, frozen balances or a freeze on another chain (frozen_elsewhere): get_address_compliance. Not for taint hops or the haircut: get_address_exposure. Not for open allowances: get_address_approvals. 'unknown' means the check did not finish, never 'checked clean'; evidence and incomplete_reasons name the cause (e.g. time_budget: the exposure walk was cut, a quieter moment may complete it). The freeze input is this chain's per-token status alone: frozen/seized argues for high (not a row with own_token_contract: the issuer's act on its own token contract), and an 'unknown' status or a pair whose freeze history is not backfilled turns a would-be 'none' into 'unknown' — so a Solana tier, where every freeze pair is unknown, is never 'none'. The exposure walk behind the tier is fixed at 3 hops; pick depth and window with get_wallet_graph_walk. A verdict is reused for up to 60 s (10 s after a time_budget cut). Heavy read: under load it answers busy or timeout — retry with backoff. No auth; 1200 requests/min shared by all tools. Not an identity, AML or legal determination.

Input Schema

Name	Required	Description	Default
`chain`	No	Chain, in any of four spellings: the id (8453 Base — default for 0x addresses; a T… address defaults to Tron and a base58 one to Solana, 1 Ethereum, 10 Optimism, 42161 Arbitrum, 56 BNB Chain, 728126428 Tron, -1 Solana), the same id as a string, the network slug (base, ethereum, optimism, arbitrum, bnb-chain, tron, solana) or its CAIP-2 id (eip155:1, solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp). Surrounding whitespace, a leading + and leading zeros are ignored, a JSON number counts by its value (1.0 is 1), slugs and CAIP-2 ids match in any letter case, and an empty, blank or null chain is no chain at all. Anything else (hex, a decimal fraction, a zero-padded CAIP-2 reference) is refused, and so is a network this scanner knows but does not index — by name, never with an empty clean verdict. The answer is about ONE chain: chain_id says which, chain_source says how it was chosen (explicit\|default\|address_form) and chains_with_data lists where else this address has data — read it before concluding, then ask again with chain set
`address`	Yes	The address to check. The address in its network's own spelling: 0x… for EVM chains, T… for Tron, base58 for Solana. The answer writes it in the spelling of chain_id (address) and echoes what you sent (requested_address); address_respelled true means your spelling belongs to another kind of chain than chain_id (a T… address asked about an EVM chain, a 0x… address asked about Tron) — answered about the same bytes there, not refused, and the same owner only for a plain key account.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 5, 2026

changedInput schema / properties / address / description

Previous value: -"the address to check (0x hex for EVM, or base58 for Solana)"New value: +"The address to check. The address in its network's own spelling: 0x… for EVM chains, T… for Tron, base58 for Solana. The answer writes it in the spelling of chain_id (address) and echoes what you sent (requested_address); address_respelled true means your spelling belongs to another kind of chain than chain_id (a T… address asked about an EVM chain, a 0x… address asked about Tron) — answered about the same bytes there, not refused, and the same owner only for a plain key account."

changedInput schema / properties / chain / description

Previous value: -"Chain, in any of four spellings: the id (8453 Base — default for 0x addresses; a T… address defaults to Tron and a base58 one to Solana, 1 Ethereum, 10 Optimism, 42161 Arbitrum, 56 BNB Chain, 728126428 Tron, -1 Solana), the same id as a string, the network slug (base, ethereum, optimism, arbitrum, bnb-chain, tron, solana) or its CAIP-2 id (eip155:1, solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp). Unknown spellings are refused, and so is a network this scanner knows but does not index — by name, never with an empty clean verdict. The answer is about ONE chain: chain_id says which, chain_source says how it was chosen (explicit|default|address_form) and chains_with_data lists where else this address has data — read it before concluding, then ask again with chain set"New value: +"Chain, in any of four spellings: the id (8453 Base — default for 0x addresses; a T… address defaults to Tron and a base58 one to Solana, 1 Ethereum, 10 Optimism, 42161 Arbitrum, 56 BNB Chain, 728126428 Tron, -1 Solana), the same id as a string, the network slug (base, ethereum, optimism, arbitrum, bnb-chain, tron, solana) or its CAIP-2 id (eip155:1, solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp). Surrounding whitespace, a leading + and leading zeros are ignored, a JSON number counts by its value (1.0 is 1), slugs and CAIP-2 ids match in any letter case, and an empty, blank or null chain is no chain at all. Anything else (hex, a decimal fraction, a zero-padded CAIP-2 reference) is refused, and so is a network this scanner knows but does not index — by name, never with an empty clean verdict. The answer is about ONE chain: chain_id says which, chain_source says how it was chosen (explicit|default|address_form) and chains_with_data lists where else this address has data — read it before concluding, then ask again with chain set"

changedInput schema / properties / chain / type

Previous value: -[
-  "integer",
-  "string"
-]New value: +[
+  "integer",
+  "string",
+  "null"
+]

First observedSep 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Stablecoin Scanner tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?