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

Annotations already declare read-only, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: the call costs $0.002 in USDC on Base via x402, meaning the agent must handle a payment flow before invocation, and it discloses the semantic meaning of returned flags (fresh/unused address, holds bridged USDbC). It does not cover failure modes such as insufficient payment balance or rate limits.

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 dense clauses that are well front-loaded: cost first, payload second, when-to-use last. The token ticker list is long but each entry earns its place by telling the agent what coverage exists. Minor density cost, no filler sentences.

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, so the description must convey return content, and it does by enumerating balances, nonce, account type, and flags. With a single fully documented parameter and annotations covering safety, the definition is nearly complete; only payment failure behavior and response shape (per-token structure) are left implicit.

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?

With one parameter at 100% schema coverage and a regex pattern plus 'Base address' description in the schema, the schema carries the semantics. The description adds nothing about the address argument (e.g., checksummed vs lowercase, contract addresses allowed), so baseline 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 (Base wallet snapshot) and enumerates exactly what one call returns: ETH and canonical token balances, nonce, EOA-vs-contract classification, and address flags. An agent knows precisely what it gets, though the definition never names or distinguishes itself from plausible siblings like token_check or usdc_payment_check.

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?

"Use before sending funds or accepting a counterparty" gives a clear triggering condition tied to a real workflow decision. It stops short of exclusions or naming an alternative tool for adjacent needs (e.g., single-token checks), so the guidance is contextual rather than exhaustive.

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