Skip to main content
Glama

Eagle Virtual USDT & USDC Blacklist Tracker

by com.eaglevirtual
OverviewDiscussionsAdmin

Recent stablecoin blacklistings and freezes

list_freeze_events
Read-onlyIdempotent

The published feed of recent stablecoin blacklist, freeze, seizure, release and on-chain sanctions events, the same rows eaglevirtual.com shows publicly, with the wallet, coin, blockchain, date, block and transaction for each. Covers every coin on every chain: omit the filters and it returns all of them, newest first. Filter by coin, blockchain, event kind or date to narrow it. This is a published sample of the record, not the full corpus, and there is no way to page beyond it. Add month (YYYY-MM) for one whole recorded month: the month’s totals on every plan, and every event behind them on the Business plan. To check a specific wallet, use get_address_status; for totals use get_token_statistics.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoRestrict to one kind of event. "blacklist" is a deny-list entry in the token contract; "freeze" locks an account; "seizure" took the balance; "release" lifted a restriction; "sanctions" is an on-chain sanctions listing; "delisting" removed one. Omit for all.
chainNoBlockchain name or chain id, e.g. Tron or 1.
limitNoRows to return, up to 100. Defaults to 25.
monthNoOne whole recorded month, YYYY-MM, instead of the recent feed. Every caller gets the month’s totals; the events behind them come with the Business plan.
sinceNoOnly events on or after this date, YYYY-MM-DD.
tokenNoCoin symbol, e.g. USDT.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / kind / description
      Previous value: -"Restrict to one kind of event."New value: +"Restrict to one kind of event. \"blacklist\" is a deny-list entry in the token contract; \"freeze\" locks an account; \"seizure\" took the balance; \"release\" lifted a restriction; \"sanctions\" is an on-chain sanctions listing; \"delisting\" removed one. Omit for all."
  2. Changed1 schema field changed
    • changedInput schema / properties / month / description
      Previous value: -"One whole recorded month, YYYY-MM, instead of the recent feed. Without an account the last 6 months can be listed, with a free account the last 12 months, and every month on the Business plan."New value: +"One whole recorded month, YYYY-MM, instead of the recent feed. Every caller gets the month’s totals; the events behind them come with the Business plan."
  3. Changed1 schema field changed
    • addedInput schema / properties / month
      Added value: +{
+  "description": "One whole recorded month, YYYY-MM, instead of the recent feed. Without an account the last 6 months can be listed, with a free account the last 12 months, and every month on the Business plan.",
+  "maxLength": 7,
+  "minLength": 7,
+  "pattern": "^\\d{4}-(0[1-9]|1[0-2])$",
+  "type": "string"
+}
  4. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds material behavioral context the annotations cannot: this is a published sample rather than the full corpus, there is no pagination beyond it, and event-level rows behind a month's totals require the Business plan. The only minor gap is that it doesn't clarify ordering consistency across filter combinations beyond 'newest first'.

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-loads what the feed is, then the default/filter behavior, then the sample/pagination caveat and plan gating, then sibling routing. Dense but every sentence contributes; minor redundancy between the opening field list and the filter sentence.

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 supplies the return shape (wallet, coin, blockchain, date, block, transaction), plus the corpus limitation, pagination ceiling, and plan-tier behavior. An agent has everything needed to call and interpret the result 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 description coverage is 100%, so all six parameters are already documented with enums and formats in the schema. The description restates the filterable dimensions and the month semantics, adding little beyond what the schema provides, which is the baseline-3 situation.

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 (list) and resource (stablecoin blacklist/freeze/seizure/release/sanctions events), enumerating the event kinds and the fields returned. It explicitly distinguishes itself from get_address_status and get_token_statistics, so an agent can route 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?

Gives explicit when-to-use: omit filters for everything newest-first, filter by coin/chain/kind/date to narrow, add month for a whole recorded month, and names two alternatives (get_address_status for a wallet, get_token_statistics for totals). Both the default behavior and the routing conditions are stated.

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