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

Beyond readOnly/idempotent/openWorld annotations, it discloses the unusual two-mode behavior: by default it returns an x402 request descriptor (GET /evm/native-balance, $0.001 per call) that must be invoked with an x402/MPP client, while a P0 access key makes it perform the paid call and deduct the price. Cost, auth header format, and the pre-charge validation guarantee are exactly the traits annotations cannot convey.

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 use case and free of filler, but it is one dense paragraph mixing purpose, payment mechanics, an inline purchase URL, and behavioral caveats. Slightly long and unstructured, though nearly every clause carries actionable 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?

With no output schema, the description still explains the return payload (wei, decimal amount, block number, as_of) and the indirection of the x402 response envelope with schema and example. An agent has everything needed to call it and to interpret either result shape.

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 chain enum plus address pattern are already self-documenting, so baseline 3 applies. The description restates the chain list and clarifies the returned coin varies by chain (ETH vs POL), but adds no format or defaulting detail 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 verb and resource ('native coin balance (ETH or POL) of an address') plus the exact chain scope (Base, Ethereum, Arbitrum, Polygon, Optimism). It also names the sibling it is not: 'for stablecoins or several chains use wallet_balance', so an agent can separate it from wallet_balance and evm_erc20_balance without reading 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?

Opens with an explicit 'Use when...' condition, gives a negative case routed to a named alternative (stablecoins/multi-chain → wallet_balance), and adds a safety rule ('Bad input is refused before any charge'). Nothing about when to select this tool is left to inference.

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