Eagle Virtual USDT & USDC Blacklist Tracker

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read. The description adds value by explaining the return format (record of actions with issuer, chain, date, tx, block) and explicitly disclaiming that it never returns a risk score or opinion. It also notes the 'no account needed' requirement, which is useful behavioral context beyond 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose, then details the return content, coverage, and exclusions. It is slightly longer than the minimum needed, but every sentence contributes—no filler. The length is justified given the need to clarify that this is a factual record, not a risk score.

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 a single parameter fully documented in the schema and no output schema, the description carries the full burden of explaining what the agent will receive. It clearly states the return structure (every recorded action with issuer, chain, date, transaction, block) and explicitly denies producing risk scores, ratings, or opinions. This is complete for an agent to call the tool correctly without further context.

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%, and the address parameter's description thoroughly explains accepted formats, case sensitivity, and examples. The tool description adds no extra semantic meaning about the parameter itself; it only clarifies the output. With full schema coverage, a baseline of 3 is appropriate.

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 opens with a specific verb+resource: 'Check one wallet address against the record of stablecoin blacklistings, freezes and seizures.' It clearly distinguishes its output (a dated record of issuer actions) from a risk score, which separates it from potential sibling tools that might offer summaries or ratings. The scope is explicit about coverage of coins and blockchains.

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 description states 'Needs no account' (a prerequisite) and implies it is for a single address, but it never explicitly contrasts this tool with siblings like list_freeze_events or get_token_statistics. An agent can infer usage from 'one wallet address,' but there is no direct 'use this when…' or 'for aggregate data use X instead' guidance.

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 (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds genuinely useful behavior: that blacklist/freeze rows rank by balance-at-restriction while seizure rows rank by balance-taken, and that scope changes which identifying fields appear. No auth, rate-limit, or pagination context is given.

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 ordering, then examples, filters, and the ranking/scope caveats. Five sentences with no filler; slightly long, but each clause 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 read-only, 5-parameter tool with no output schema, the description adequately explains row content (wallet, date, block, transaction for the recent scope; none for all_time). It does not enumerate the full returned field set (amount, coin, chain, kind), a minor gap.

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 the baseline is 3. The description adds real meaning on top of the schema by clarifying how the ranking quantity differs between blacklist/freeze and seizure, and by restating the scope-dependent output fields, but filter parameters themselves add little beyond the schema.

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 operation/ordering (ranked by amount, largest first), plus concrete questions it answers. It does not name the overlapping sibling (list_freeze_events) that an agent might otherwise choose, so it stops short of full sibling 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?

Gives clear context for use via example questions ("what is the largest blacklist") and explains the available filters (coin, blockchain, kind) and the scope choice. It never states when NOT to use it or which sibling to prefer instead, so it lacks exclusions/alternatives.

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 closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: certain chains have records 'behind right now' and cannot be vouched for, and the `coins` array is a strictly smaller set than the claimed coverage. It stops short of describing pagination or the exact shape of the staleness signal.

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 what it returns, then the call-to-action, then the field-level distinctions. Every sentence carries information, though the single dense paragraph and the final run-on clause about issuer naming are slightly harder to parse than they need to be.

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 output schema and no parameters, the description carries the full burden of explaining return content, and it names the key fields (chains_claimed, coins_covered, contracts_checked, companies_checked) plus the caveat about lagging chains. It does not fully specify the response structure, leaving some gaps an agent must discover at call time.

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?

The tool takes zero parameters, so the schema has nothing to document and the baseline is 4. The description correctly spends no effort on parameter semantics.

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 (the coverage of the stablecoin blacklist/freeze record) and enumerates what it returns: covered blockchains and coins, the date of the most recent recorded event, and which chains are currently behind. It is clearly distinguishable from event-listing siblings like list_freeze_events because it is metadata about the record itself, not the 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 explicit when-to-use guidance: call it to determine whether a chain or coin is in scope before relying on an answer, and to check whether any part of the record is lagging. It does not name an alternative or state when-not to use it, but no sibling competes for this purpose.

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

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.

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.

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.

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.

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.