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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description adds substantial behavioral detail: the exact costBtc formula, the odds formula 1-(1-s)^n, the BTC unit convention, the handoff's mrrApi block, and the guarantee that null fields mean an unavailable feed with no fabrication. Each statement enriches the annotation without contradicting them.

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?

Four dense sentences pack a large amount of information without redundancy. The flow moves logically from what it is, to formulas and units, to limitations and the handoff, to null-handling, with every sentence earning its place. It could be tightened slightly (e.g., the 'rental itself is completed on MiningRigRentals' clause appears twice in slightly different forms), but it remains appropriately brief for the complexity.

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 no-output-schema tool with two optional parameters, the description covers all necessary aspects: purpose, formulas, units, exclusions, handoff contents, and error/null behavior. An agent has everything needed to invoke it correctly and understand what to expect, even without a formal response schema or title.

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 describes both parameters at 100% coverage, so the baseline is 3. The description adds meaning beyond the schema by explaining the default of 3 hours, the clamping behavior when outside a machine's window, and the effect of omitting machineId (quote all machines). The costBtc formula further ties the parameters to the returned data, beyond what the schema provides.

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 opens with a precise verb ('Live rental quote'), names the exact resource (Galaxy Mind's named USA ASICs on MiningRigRentals) and lists three concrete outputs (cost, block odds, current block prize). It also explicitly states what the tool cannot do ('cannot rent and cannot move funds'), eliminating any ambiguity against shopping/price sibling tools.

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?

It clearly explains when to use the tool (for a quote on Galaxy Mind's ASICs), when not to (it can't rent or transfer funds), and even contrasts its BTC-denominated pricing with the USD/PH/day convention used by external hashprice indices. Although it doesn't name a sibling tool, it does specify the handoff point (MiningRigRentals), giving sufficient context for an agent to route requests. Omitting an explicit alternative tool name keeps it a 4 rather than a 5.

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