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

With no annotations, the description carries the full burden and does disclose the cost (0.02 USDC on Base) and the scope of results (native and USDC). It omits error behavior or authentication requirements, but the cost disclosure adds value beyond 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?

Two sentences, front-loaded with the primary action, and each sentence serves a purpose: address format, chain options, default, and cost. No redundant wording.

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 simple read-only tool with no output schema, the description covers input parameters, return type (native and USDC balances), and cost. It is slightly ambiguous whether the cost applies only on Base or all chains, but overall it's adequate.

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 has 0% description coverage, so the description fully compensates by specifying the address format (0x...), enumerating chain values (base, ethereum, polygon, arbitrum, optimism), and stating the default (base). This is essential meaning absent from 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?

The description clearly states the tool's function with a specific verb ('Query') and resource ('native and USDC balance for any EVM wallet address'). It distinguishes from sibling tools like fetch_url or token_price by focusing on wallet balance.

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 provides clear usage context: it's for querying balances of EVM addresses, with an optional chain parameter and default base. However, it does not explicitly mention alternatives or exclusions, so it lacks when-not-to-use guidance.

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