Hive Mining

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

The description mentions a cost of $0.02 USDC and a 'consume_tx hash for audit', but it fails to disclose whether the operation is read-only, destructive, or other safety aspects. With no annotations provided, this is insufficient for an agent to infer behavioral traits.

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 description is relatively short but includes unnecessary jargon and extraneous details about payment settlement. It front-loads the core function but could be more streamlined and focused.

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?

Given no output schema and no annotations, the description should explain return values comprehensively. It mentions 'fee landscape' and 'candidate pool' but does not specify structure or format, leaving the tool's output ambiguous.

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 input schema has no parameters, and schema coverage is 100%. The description adds some meaning by describing the output (fee landscape and candidate pool), but it does not explain the significance of the lack of parameters or how the tool uses context. Baseline 3 is appropriate as the description adds minimal value beyond the empty 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 mentions 'Bitcoin mempool fee landscape + nextblock candidate pool', but it is muddled with cryptic terms like 'Bortlesboat-attributed' and details about USDC settlement. The core purpose is unclear, especially as it does not distinguish from similar sibling tools like 'next_block_forecast'.

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?

No guidance is provided on when to use this tool versus alternatives such as 'next_block_forecast' or other mining-related tools. There is no mention of prerequisites, context, or when not to use it.

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

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

No annotations are provided, so the description carries the full burden. It states the tool returns specific fields (pending_usdc, settle_chain, settle_asset, payout_threshold_usdc) and mentions the backend endpoint. However, it does not disclose authentication needs, rate limits, or error handling behavior.

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 description is two sentences long, providing key information (purpose, tier, return fields, backend) without extraneous text. It is front-loaded with the main action and context.

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 query tool with one parameter and no output schema, the description adequately covers purpose, return fields, and implementation detail. It could be improved by noting common error scenarios or usage within a workflow, but overall it is sufficient.

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% for the only parameter 'operator_did', and the description repeats the schema description without adding additional meaning or usage nuance. Baseline 3 is appropriate since the schema already fully defines the parameter.

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 verb 'Get' and the resource 'an operator's pending USDC payout balance' from the Hive earn rails ledger. It distinguishes itself from siblings like 'payout_btc_to_usdc' by specifying the query purpose and return fields.

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 implies usage for checking pending USDC balance with a tier and amount ($0.001 USDC), but does not explicitly state when to use this tool versus alternatives, nor when not to use it. The usage context is implied through the sibling list.

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

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

Explicitly states 'Read-only' indicating no side effects, and mentions cost tier ($0.001 USDC). No annotations provided, so description covers basic behavioral safety and cost. Missing details on error handling or auth requirements beyond operator_did parameter.

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 sentences carrying essential information: purpose, read-only, cost, return summary, and backend. No redundancy, front-loaded with key details.

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 1-param tool with no output schema, description covers purpose, behavior, cost, and return summary. Missing details on edge cases like invalid operator_did, but overall 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?

Schema description coverage is 100% with a detailed parameter description including example and source. Description adds return context but no extra parameter semantics. Baseline score of 3 applies as schema does the heavy lifting.

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?

Description clearly states the tool queries registered Tether MOS sites and telemetry via Hive orchestration. It specifies verb 'Query', resource 'operator's registered Tether MOS sites and latest site telemetry', and context. Differentiates from sibling 'mos.query_payouts' which handles payouts.

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?

No explicit guidance on when to use vs alternatives. Purpose is implied by name and return summary (sites vs payouts), but no direct exclusions or when-not-to-use advice.

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

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

No annotations provided, and description only mentions cost ($0.03 USDC) and combination of sources. Does not disclose rate limits, auth needs, or return format.

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 concise sentences, front-loaded with action and context. Every sentence adds value.

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 and no annotations, description covers purpose and cost but lacks details on output format or example forecast.

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?

No parameters to describe; schema coverage is 100%. Description adds no parameter info, but baseline is 4 due to zero parameters.

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 forecasts the next-block fee window using auction state and external advice, with a specific use case. It distinguishes from sibling tools like bitcoin_fee_advice.

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?

Explicitly mentions usefulness for fee-sensitive submitters timing transactions, providing clear context. Does not mention when not to use or alternatives.

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

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

With no annotations, the description discloses the swap flow, fee (40bps), and error return (503). It implies a write action (deposit) but does not detail response format or idempotency.

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 succinct sentences, front-loaded with core purpose, followed by fee and error condition. No superfluous text.

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?

Given limited parameters and no output schema, the description covers the swap mechanism, fee, and error. Could specify that the tool returns an HTLC address, but overall 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?

Schema coverage is 50%: recipient_usdc_address has a schema description. The tool description does not add detail for btc_amount_sats beyond type and exclusiveMinimum, and does not clarify units or format beyond what schema implies.

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 it's a 'Boltz reverse swap' and explains that deposit BTC yields USDC on Base. It distinguishes from sibling tools which are mining or Bitcoin fee advice.

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 explains the atomic swap and provides conditions (fee, error when disabled). It does not explicitly mention when to use vs alternatives, but no sibling tool is similar.

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