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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered; the description adds the actual computation model and the outputs produced (revenue, electricity cost, profit per day/month/year, break-even electricity price, payback days, J/TH). It also flags argument-shape constraints — fields must be nested under inputs and the REST calculator field must not be passed — which is real behavioral guidance beyond 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 formula and output list are front-loaded and useful, but the trailing sentences ('Follow its required fields and exact choices', 'Supply units or modelVersion only when listed in inputSchema') are procedural filler that partly restate what the schema already enforces.

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?

An output schema exists, so return values needn't be explained, and annotations cover safety. However, for a nested twelve-field input object with zero schema descriptions, the definition leaves several inputs semantically undefined and gives no guidance on units for power or electricity price, so it is only adequate rather than complete.

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 description coverage is 0% and the nested inputs object holds twelve sub-fields, so the description carries a heavy burden. The formula maps meaning onto hashrate, network hashrate share, blocks/day, block reward, fees and pool fee, and the 'put tool fields inside inputs' line clarifies the wrapper, but hardware_cost, coin_price, power_watts and pool_fee_pct defaults remain undefined.

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 computation (proof-of-work mining expected value) and spells out the formula, so an agent can distinguish it from fee, staking-yield, or unit-conversion siblings. It does not explicitly name an alternative tool, but the verb+resource+formula combination is unambiguous.

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?

There is no when-to-use or when-not-to-use guidance and no named alternative among the many buscalc_chain_* siblings. The scenario (mining profitability) is inferable, but the description never states the conditions that select this tool over, say, buscalc_chain_staking_yield or buscalc_chain_cost_basis.

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