Eagle Virtual USDT & USDC Blacklist Tracker

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, but the description adds what annotations cannot: the exact shape of the returned record (issuer, blockchain, date, transaction, block), that results are independently verifiable, that no account is required, and an explicit non-goal (never a risk score or opinion). With no output schema, this disclosure is doing real work.

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?

Sentences are front-loaded with the core action and each adds a distinct fact (coverage, return content, non-goal, no auth). Minor redundancy in 'Covers USDT, USDC and every other coin in this record, on every blockchain it checks', which restates coverage twice.

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?

For a single-parameter read tool with no output schema, the description covers the return payload, the auth posture, and the interpretive limits of the data. Nothing an agent needs in order to call and interpret this tool 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 already documents accepted formats (EVM, TRON, Solana, Stellar, case-insensitive) and max length. The description adds no parameter-level detail beyond what the schema provides, 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?

States a specific verb and resource ('Check one wallet address against the record of stablecoin blacklistings, freezes and seizures'), and the scope (single address, all issuers, all chains) clearly separates it from the event-listing sibling list_freeze_events.

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 clear context for when this is the right call ('check one wallet address', 'needs no account') and clarifies the use case vs. a risk-scoring service. It stops short of naming an alternative such as list_freeze_events or get_coverage for the case where the agent wants bulk event data rather than a single-address lookup.

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 safe-read profile, and the description adds genuinely new behavioral detail: the differing ranking quantity for blacklist/freeze (post-restriction balance) vs seizure (taken balance), the 6-month default window, and the fact that all_time rows omit wallet, transaction and block back to 2018. That is meaningful context an agent could not derive from the schema.

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 resource and ordering, then moves through questions, filters, ranking semantics, and scope. Every sentence carries information; nothing is padding.

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, yet the description specifies what each row contains (wallet, date, block, transaction) and how the two scope modes differ in returned fields. For a read-only ranked-list tool it is complete enough to invoke 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 schema already documents all five parameters, but the description reinforces scope semantics with a consequence (all_time names no wallet/tx/block) and clarifies the ranking quantity per kind. It adds some value on top of the schema rather than none.

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 resource (stablecoin blacklistings, freezes, seizures, releases) and a specific ordering (ranked by amount, largest first), plus the exact questions it answers. An agent can distinguish it from list_freeze_events purely on the ranking/aggregation framing.

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 clear triggering questions ('what is the largest blacklist', 'the biggest freeze') and the filtering conditions (coin, blockchain, kind). It does not explicitly exclude or name the overlapping sibling list_freeze_events, so the when-not-to-use case 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 declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, destructiveHint=false, so the agent knows it's a safe, non-destructive, idempotent read. The description adds that some lanes may be unvouched and that the record may be behind, which is useful caveat context. However, it doesn't describe response shape or how freshness is computed. With annotations covering safety, a 3 is appropriate.

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 a single dense paragraph that front-loads the main purpose but then packs in field-level semantics and a disambiguation about coin names. It is informative but not tightly structured; some sentences could be split or moved. It earns its length but at the cost of scannability.

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 input parameters, no output schema, and rich annotations, the description is nearly complete. It covers purpose, usage condition, and key semantic distinctions about the data. One gap is that it doesn't explain how 'lanes we cannot currently vouch for' are represented or whether there's a caveat about data latency beyond 'behind'. Still, it's sufficient for an agent to call this 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?

There are 0 parameters, so baseline is 4. The description goes further by explaining the semantics of the output fields (`chains_claimed`, `coins_covered`, `contracts_checked`, `companies_checked`, and `coins`), clarifying that `coins` is a smaller set (only those with recorded events) and that duplicate names per issuer appear once per issuer. This is valuable semantics despite referring to output rather than input.

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 clearly states the resource: coverage scope of the stablecoin blacklist/freeze record, recency of events, and lanes that cannot be vouched for. It distinguishes itself from siblings like get_token_statistics and list_freeze_events by focusing on metadata about the record itself rather than the events. It is slightly sprawling but specific about what it returns.

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 when to call: 'before relying on an answer about it' and 'to check whether any part of the record is behind.' This gives a clear condition for usage. It doesn't name alternatives (e.g., go elsewhere for event data), which keeps it from a 5.

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 read-only, idempotent, non-destructive. The description adds real behavioral context beyond them: output is event signature + count + first/most recent dates, absence of records does not imply incapability, and no wallets are disclosed (a privacy boundary). That last point is genuinely informative for an agent deciding on disclosure.

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 core purpose, but the middle clause is repetitive — 'does not report what a contract is capable of: contract capability inspection is not published yet, and this tool says so rather than inferring that a coin cannot freeze from an absence of records' restates the same caveat three ways in one sentence.

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?

Single optional parameter, no output schema, read-only tool: the description supplies the return content (event name, count, date range) and the key semantic caveat about absence of records, which is what an agent needs. The main omission is any explicit pointer to sibling tools for adjacent questions.

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 single token parameter is fully documented in the schema (ticker examples, multi-issuer collision behavior, omit-for-all). The description adds only 'for a given coin', which duplicates the schema, so baseline 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?

States a specific resource and verb-like framing: per-coin record of restriction controls the issuer has actually used (blacklisting, freezing, balance-taking, lifting), plus the returned fields. It implicitly separates itself from list_freeze_events by scoping to per-issuer usage, but never names a sibling tool, so it falls short of full differentiation.

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?

Usage is implied rather than stated: 'Reports what has happened, dated' tells the agent this is a historical-usage lookup, and 'contract capability inspection is not published yet' warns of a common misuse. But no alternative tool (e.g. list_freeze_events or get_address_status) is named for related questions, so the agent must infer routing.

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 safety (readOnly, idempotent, non-destructive, closed-world). The description adds the meaningful data-scope disclosure that only counts and dates are returned and no wallet addresses are exposed, which tells the agent what it will and will not get back.

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?

Three sentences, front-loaded with the core capability, followed by example intents and the output-scope constraint. Every sentence carries distinct information with no padding.

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 and no required parameters, so the description carries little extra burden; annotations supply the safety profile. It is nearly complete, missing only a note on the default grouping, which the schema already provides.

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 restates the breakdown dimensions (coin/blockchain/month/year) that the group_by enum already defines, adding little beyond what the schema documents, and omits the default of 'token'.

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 (counts) and resource (stablecoin blacklistings, freezes, seizures) with the supported breakdown axes. An agent can distinguish it at a glance from row-returning siblings like list_freeze_events.

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?

The three example questions ('how many wallets has Tether blacklisted', 'which coin is frozen most often', 'how many seizures happened in 2025') give concrete selection cues. However, it never names list_freeze_events as the alternative for individual events, so the routing is implied rather than explicit.

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 declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the feed is a published sample rather than the full corpus, there is no pagination, results are ordered newest first, and access depth is tiered by account (6/12/all months). This is exactly the behavioral detail an agent needs before committing to a query.

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 purpose and result shape, then filters, then constraints, then alternatives — a logical progression with no filler sentences. It is slightly long, but each sentence carries distinct information.

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?

For a six-parameter read tool with no output schema, the description covers result contents ('each result reports which chains, coins and issuers it actually contains'), ordering, pagination limits, and account-tier restrictions. 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%, so baseline is 3; the description still adds the default ordering (newest first) and the semantics of omitting all filters, plus the month-vs-recent-feed distinction. It does not add per-parameter syntax beyond what the schema already documents.

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 resource (published feed of stablecoin blacklist/freeze/seizure/release/sanctions events) with the exact fields returned (wallet, coin, blockchain, date, block, transaction). It clearly distinguishes itself from siblings by naming get_address_status and get_token_statistics as the tools for wallet checks and totals.

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?

Explicitly tells the agent how to use it (omit filters for everything, newest first; narrow by coin, chain, kind or date) and what it cannot do (no paging beyond the published sample). It also names the two alternative tools and the conditions that select them.

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