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

Annotations already establish read-only, idempotent, open-world, and non-destructive behavior. The description adds substantial behavioral context beyond annotations: only non-zero holdings are returned, values are enriched live via DexScreener, calls are priced at $0.02, prepaid x-credit-token header enables unlimited calls, and one free call per day is allowed. No contradictions exist with 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 front-loaded with the core purpose and token list, then efficiently covers behavioral details (non-zero only), required input, pricing, auth, and free-tier availability. Every sentence carries useful information with no filler or repetition.

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?

Given the simple single-parameter schema, rich annotations, and presence of an output schema, the description covers everything an agent needs to decide when and how to call this tool: chain scope, token scope, filter behavior, authentication requirements, and cost. Nothing essential 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?

The schema already documents the single required parameter 'address' with 100% coverage. The description adds meaningful context by stating the address must be a Base address and that the tool works for any address, reinforcing that no pre-registration or API key is needed. This adds value beyond the schema's generic 'Wallet address' description.

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 names a specific verb ('Returns') and a precise resource ('ETH + major Base token balances with USD values') and enumerates exactly which tokens are covered (native ETH plus WETH, USDC, USDbC, DAI, cbETH) for any Base address. This makes the tool's scope immediately distinguishable from broader sibling tools like wallet_portfolio or wallet_networth.

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 clearly states the intended use case: retrieving non-zero token balances with USD values for any Base address. It also specifies the required input, clarifies that no wallet or API key is needed, and mentions pricing and free-call availability. It does not explicitly contrast this tool with sibling alternatives, so it stops just short of full routing guidance.

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