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

Beyond readOnlyHint/destructiveHint annotations, it discloses that failures are uncharged and that repeat calls cost money — directly explaining the idempotentHint=false flag in cost terms — plus the pricing model ($0.01/call, x402 USDC or card key via /credits, first 25 free). That is meaningful behavioral context an agent cannot get from the structured fields.

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 semantics and alternatives before pricing and error codes, so it is scannable despite being a single dense paragraph. Minor waste: 'Reads or computes only and changes nothing' largely duplicates the readOnlyHint/destructiveHint annotations.

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 still tells the agent what comes back (count plus collection name and symbol); with only two required params, the schema covers inputs. Error codes, cost model, and the sibling routing together make it complete enough to invoke correctly on the first attempt.

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 both properties already document themselves as '0x ... address'. The description's 'Both inputs are 0x addresses' restates that without adding format, checksum, or validation nuance, so it neither compensates for nor detracts from the schema. 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 verb and resource — count of NFTs held in one ERC-721 collection by one wallet on Avalanche — and names the underlying call (balanceOf) plus the returned extras (name, symbol). It explicitly distinguishes itself from the closest sibling, avax_nft_owner, so an agent can pick between them without opening either schema.

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 two concrete use cases (gate a holder before a token-gated action, check whether a wallet still holds a collection) and an explicit alternative with its selection condition ('for who holds one token id use avax_nft_owner'). It goes further and states the failure surface: missing contract is 404, non-ERC-721 contract is 422.

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