Eagle Virtual USDT & USDC Blacklist Tracker

Check whether a wallet has been blacklisted or frozen

get_address_status

Read-onlyIdempotent

Check one wallet address against the record of stablecoin blacklistings, freezes and seizures. Returns every recorded action against that address — which issuer took it, on which blockchain, on what date, and in which transaction and block, so it can be verified independently. Covers USDT, USDC and every other coin in this record, on every blockchain it checks. Returns a dated record of what an issuer did, never a risk score, rating, or opinion about the address or its owner. Needs no account.

Input Schema

Name	Required	Description	Default
`address`	Yes	The wallet address to check, in any format the chain uses. Accepts Ethereum-style addresses (used by Ethereum and many other chains), addresses on Tron, Solana, Stellar, TON, the XRP Ledger, Aptos, Starknet, Sui and the TX Chain, and NEAR account names that end in .near. An Ethereum-style address works in all small letters, all capitals, or with the capitals the wallet shows. Any other mix of capitals is read as a typo. For every other kind of address, keep the capital and small letters as the wallet shows them.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

changedInput schema / properties / address / description

Previous value: -"The wallet address to check, in any format the chain uses. Accepts Ethereum-style addresses (used by Ethereum and many other chains), addresses on Tron, Solana, Stellar, TON, the XRP Ledger, Aptos, Starknet and Sui, and NEAR account names that end in .near. An Ethereum-style address works in all small letters, all capitals, or with the capitals the wallet shows. Any other mix of capitals is read as a typo. For every other kind of address, keep the capital and small letters as the wallet shows them."New value: +"The wallet address to check, in any format the chain uses. Accepts Ethereum-style addresses (used by Ethereum and many other chains), addresses on Tron, Solana, Stellar, TON, the XRP Ledger, Aptos, Starknet, Sui and the TX Chain, and NEAR account names that end in .near. An Ethereum-style address works in all small letters, all capitals, or with the capitals the wallet shows. Any other mix of capitals is read as a typo. For every other kind of address, keep the capital and small letters as the wallet shows them."

Changed1 schema field changedSep 25, 2026

changedInput schema / properties / address / description

Previous value: -"The wallet address to check, in any format the chain uses. Accepts Ethereum-style addresses (used by Ethereum and many other chains), addresses on Tron, Solana, Stellar, TON, the XRP Ledger, Aptos, Starknet and Sui, and NEAR account names. An Ethereum-style address works in all small letters, all capitals, or with the capitals the wallet shows. Any other mix of capitals is read as a typo. For every other kind of address, keep the capital and small letters as the wallet shows them."New value: +"The wallet address to check, in any format the chain uses. Accepts Ethereum-style addresses (used by Ethereum and many other chains), addresses on Tron, Solana, Stellar, TON, the XRP Ledger, Aptos, Starknet and Sui, and NEAR account names that end in .near. An Ethereum-style address works in all small letters, all capitals, or with the capitals the wallet shows. Any other mix of capitals is read as a typo. For every other kind of address, keep the capital and small letters as the wallet shows them."

Changed1 schema field changedSep 25, 2026

changedInput schema / properties / address / description

Previous value: -"The wallet address to check, in any format the chain uses. Accepts Ethereum-style addresses (used by Ethereum and many other chains) and addresses on Tron, Solana, Stellar, TON, the XRP Ledger, Aptos, Starknet and Sui. An Ethereum-style address works in all small letters, all capitals, or with the capitals the wallet shows. Any other mix of capitals is read as a typo. For every other kind of address, keep the capital and small letters as the wallet shows them."New value: +"The wallet address to check, in any format the chain uses. Accepts Ethereum-style addresses (used by Ethereum and many other chains), addresses on Tron, Solana, Stellar, TON, the XRP Ledger, Aptos, Starknet and Sui, and NEAR account names. An Ethereum-style address works in all small letters, all capitals, or with the capitals the wallet shows. Any other mix of capitals is read as a typo. For every other kind of address, keep the capital and small letters as the wallet shows them."

Changed1 schema field changedSep 23, 2026

changedInput schema / properties / address / description

Previous value: -"The wallet address to check, in any format the chain uses. Accepts EVM, TRON, Solana and Stellar forms; casing does not matter."New value: +"The wallet address to check, in any format the chain uses. Accepts Ethereum-style addresses (used by Ethereum and many other chains) and addresses on Tron, Solana, Stellar, TON, the XRP Ledger, Aptos, Starknet and Sui. An Ethereum-style address works in all small letters, all capitals, or with the capitals the wallet shows. Any other mix of capitals is read as a typo. For every other kind of address, keep the capital and small letters as the wallet shows them."

First observedSep 1, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive and closed-world behavior, and the description adds meaningful context on top: the return payload is a verifiable dated record with issuer, chain, transaction and block, and no authentication is needed. What's missing is how an empty/no-match result is represented, which matters for a 'check whether' tool.

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 the action and the return contents, and every sentence is informative. There is mild redundancy around the 'never a risk score, rating, or opinion' point, which is restated in emphasis rather than advancing new information.

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

Completeness4/5

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

With one fully documented parameter, no output schema, and rich read-only annotations, the description carries the return-shape burden well by listing the fields an agent will get back. The one gap is negative-result semantics: it never says what is returned when an address has no recorded actions, which an agent needs to interpret 'clean' answers 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 coverage is 100% and the address parameter already carries an unusually thorough description (chains supported, EVM case-handling rules, NEAR names, maxLength, examples). The tool description adds nothing about the parameter beyond that, so the schema is doing all the work — the baseline 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?

States a specific verb and scope: 'Check one wallet address against the record of stablecoin blacklistings, freezes and seizures,' and enumerates what comes back (issuer, chain, date, transaction, block). The single-address framing distinguishes it cleanly from the sibling list_freeze_events, which lists events rather than checking one address.

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?

Gives clear context for use (single address, no account required, covers USDT/USDC and every other coin in the record on every chain it checks) and explicitly rules out a competing interpretation by saying it never returns a risk score or opinion. It does not, however, name a sibling alternative or state when to prefer list_freeze_events or get_token_policy instead.

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

All Eagle Virtual USDT & USDC Blacklist Tracker 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?