Skip to main content
Glama
Sign In

Stablecoin Scanner

by com.achivx
OverviewDiscussionsAdmin

get_address_compliance

Read-onlyIdempotent

Issuer freeze/seize facts for one address on one chain, plus the OFAC SDN flag: freeze[] (one row per freeze-capable stablecoin, status frozen|seized|clear|unknown, with frozen_usd6 = the balance locked now where it was read), not_freezable[] (stablecoins whose issuer cannot freeze on this chain, e.g. the Binance-Peg wrappers on BNB Chain — enforcement is off-chain), frozen_elsewhere[] (the same address bytes under a standing freeze on another indexed chain; EVM and Tron share them, Solana never) and freeze_proposals[] (issuer multisig proposals naming the address, USDT on Ethereum and Tron: executed ones; pending ones only where the operator publishes them in full — elsewhere a pending proposal's address is shown once it executes). Use it when the question is whether an issuer or OFAC acted on this address, or how much is frozen. Not for a risk tier: get_address_risk. Not for taint distance: get_address_exposure. Not for when the OFAC list was refreshed: get_sanctions_status. Decoded on-chain issuer acts with provenance, no heuristics. 'unknown' means no act names the address and that pair's freeze history is not fully backfilled yet — absence of evidence is not 'not frozen'; an empty frozen_elsewhere[] or freeze_proposals[] means none in what is indexed, not clean everywhere. Each chain is its own issuer act: pass chain to ask Ethereum or Tron about the same bytes, chains_with_data says where. 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

NameRequiredDescriptionDefault
chainNoChain, 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
addressYesThe 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.

  1. Changed3 schema fields changed
    • 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"
+]
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness3/5

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.

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 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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Stablecoin Scanner toolsInspect
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