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

Annotations already cover readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description correctly does not waste space repeating them. It adds genuinely useful behavioral context beyond the annotations: the Poisson-process model, the warning that 'variance dominates at small hashrates, so the average alone is misleading', and that electricity cost is included in the calculation. This informs how the agent should interpret results. No contradiction with 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 description is longer than average but every sentence earns its place: definition, output list, variance caveat, usage examples, and sibling routing. The core purpose is front-loaded and the alternatives come last. Slightly dense in places, which keeps it from a 5, but there is no redundant filler or repetition of schema content.

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?

Despite having no output schema, the description explicitly enumerates what the tool returns (mean time to a block, at-least-one-block chances over five horizons, and 5th/50th/95th percentile waiting times), so the agent knows what to expect. All five parameters are documented in the schema, usage conditions and alternatives are stated, and the behavioral caveat is included. For a calculation tool of this complexity, everything needed to select and invoke it correctly is present.

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%, so the schema already documents every parameter, including subtle behavior like ambiguous coin_id rejection and hashrate_unit unit-family disambiguation. The description's first sentence mentions 'electricity cost of the attempt' which maps to the electricity_cost_usd_kwh parameter, but it adds little beyond the schema's own parameter descriptions. Baseline 3 is appropriate when the schema carries the weight.

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 states a very specific verb+resource ('Probability of a solo miner finding a block') and the computational model (Poisson process over live difficulty and hashrate). It enumerates the outputs (mean time, 1/7/30/90/365-day probabilities, 5th/50th/95th percentile waiting times) and explicitly distinguishes itself from get_cost_of_production and get_coin_oracle, so an agent can differentiate it from siblings without opening any other 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?

Provides hard-to-misuse usage guidance: three concrete example queries ('how long would it take to solo mine a Bitcoin block with 100 TH/s', 'what are my odds solo mining Kaspa', 'is solo mining worth it with this rig'). It also states explicit exclusions and alternatives: pooled mining economics or profitability should use get_cost_of_production, and raw network state should use get_coin_oracle. Nothing 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.

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

Annotations already declare this as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations: data is measured by BackPow stratum collectors, ambiguity is rejected rather than guessed, stalled networks return errors instead of zeros, and responses include a confidence block describing observation age and fallback status. No contradiction with 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 description is information-dense and well-structured: it leads with the core purpose and metrics, then confidence semantics, then error behavior, then usage and alternatives. Every sentence adds value, and there is no repetition or filler.

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 only one parameter and rich annotations, the description fully covers how the tool behaves, what the response includes, how to interpret confidence, and how to choose among siblings. Since there is no output schema, the description's explanation of return semantics and error behavior is especially important and is present.

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 already provides 100% parameter coverage with a detailed description of coin_id, including examples and ambiguous-input handling. The tool description does not add extra parameter-level semantics beyond what the schema already states, so the baseline of 3 is appropriate.

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 verb and resource: retrieving current network state for one Proof of Work chain, with concrete metrics like difficulty, hashrate, block height, reward, and block-time target. It also explicitly differentiates from siblings by naming get_cost_of_production and calculate_solo_mining_odds as the tools for economics and mining probability.

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 gives explicit usage examples ("what is Kaspa's current difficulty", "network hashrate of Monero", "current block reward") and clearly states when to use alternatives: economics uses get_cost_of_production, mining probability uses calculate_solo_mining_odds. This leaves no ambiguity about tool selection.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by disclosing what the response contains — CoP in USD, spot, gross margin, above/below water, reference machine and tariff, and a 30-day trend where a reference-machine change 'indicates the efficiency frontier moved'. This is meaningful behavioral context, though it stops short of covering failure modes for untracked coins.

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, front-loaded with the core definition, then the return payload, then usage guidance and alternatives. Dense with no filler, but the slight internal redundancy between 'gross margin' and 'whether miners are currently above or below water' keeps it just short of a perfect 5.

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 present, the description correctly carries the return-value burden and enumerates every returned component, including the 30-day trend and the reference-machine-change flag. Both parameters are fully covered by the schema, annotations cover the safety profile, and sibling routing is explicit. An agent has everything needed to select and invoke the tool correctly.

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%, and both parameters are already richly documented: coin_id explains ambiguity rejection with shared-ticker examples (DGB, XVG, TARI), and electricity_cost_usd_kwh explains the 0.069 default, the residential-rate caveat, and its impact on conclusions. The description's 'Accepts a custom electricity rate' merely restates the schema, so the 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: 'Cost of Production (CoP) for one Proof of Work coin' — the all-in electricity cost of mining one unit on the most efficient tracked hardware versus spot price. It is clearly differentiated from siblings by name ('use get_hardware_benchmarks' for a specific rig, 'calculate_solo_mining_odds' for block-finding probability), so an agent can distinguish it without opening any 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?

Explicitly enumerates the query intents this tool answers ('is mining X profitable', 'are miners underwater', 'break-even electricity price') and gives conditional exclusions with named alternatives: 'For a specific rig rather than a coin, use get_hardware_benchmarks. For block-finding probability, use calculate_solo_mining_odds.' Nothing 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.

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds behavioral context beyond that: results are ranked by profitability, results are capped (with a hint to request a higher limit), and market price may be an observed listing or a model estimate. These are useful traits not present in annotations. It doesn't add rate limits or error behavior, but with annotations covering safety, the extra detail is sufficient. No contradiction with 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 description is slightly long but every sentence adds value: first sentence states purpose and key features, second gives example queries, third explains ranking and capping, fourth routes to an alternative. It's front-loaded with the core purpose and well-structured. It's not overly verbose, though it could be trimmed slightly; still, the density is justified by the tool's 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?

Despite no output schema, the description lists the return fields (hashrate, power draw, gross revenue, net profit, market price, price type), explains ranking and capping, provides example queries, and gives an alternative tool for other use cases. With 5 parameters, this description covers all essential aspects an agent needs to call it correctly: what it does, when to use it, key behaviors, and alternatives. Nothing critical is missing.

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 100% description coverage for all 5 parameters, so the schema already documents each parameter thoroughly (type enum, limit range and default, query min length, coin_id pattern, electricity cost default and impact). The tool description adds only marginal semantic value, e.g., mentioning that electricity rate affects profitability and hinting at the limit cap. Baseline for high coverage is 3, and the description doesn't significantly exceed that.

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 states a specific verb and resource (get hardware benchmarks), and clearly defines what it does: matches mining hardware to coins, ranks by net USD/day, and covers ASICs/GPUs/CPUs. It explicitly distinguishes itself from get_cost_of_production, which is a sibling, by stating the alternative use case. The purpose is unambiguous and unique among siblings.

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 gives multiple concrete example queries ('what should I mine with an RTX 4090', 'best ASIC for Scrypt', etc.), explains the ranking basis (profitability, not alphabetical), warns about result capping and advises asking for a higher limit, and explicitly directs to get_cost_of_production when the user wants coin economics independent of hardware. This is explicit when-to-use and when-not-to-use guidance with an alternative named.

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?

Annotations already declare readOnly/openWorld/idempotent, and the description adds meaningful context: items are aggregated from third-party feeds, returned as quoted external content with publisher and relevance score, and are not BackPow statements of fact. This discloses sourcing and epistemic limits beyond the annotation hints.

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?

Three sentences, each earning its place: the core purpose, the sourcing caveat, and the usage direction with alternatives. The key purpose is front-loaded and no filler is present.

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?

Coverage is strong for a read-only news tool: it explains what the items are, their provenance, and when to use them. A minor gap is the lack of a more detailed return-structure description (e.g., fields like title, URL, date), but the stated publisher-plus-relevance-score shape is sufficient for selecting and invoking the tool.

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%, so the schema fully documents limit, coin_id, and include_low_signal. The description adds only the notion of filtering to 'one coin', which is already implied by the schema, so it does not significantly exceed the baseline.

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 ('get') and resource ('recent news items about Proof of Work mining and network events'), with an optional coin filter. It clearly distinguishes itself from sibling analytic tools by framing the content as narrative news rather than numerical data.

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 says 'Use when a question turns on recent events' and gives concrete examples (halving, difficulty swing, pool outage, chain upgrade). It also names alternatives for numeric queries: get_coin_oracle and get_cost_of_production.

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?

Annotations already mark this as read-only, idempotent, and non-destructive, and the description adds important behavior beyond that: pagination expectations, the fact that profitable_only is resolved only for the returned page, and that the response includes the algorithm list for discoverability. This directly helps the agent interpret small or partial results.

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 compact and well-structured: definition, optional filters, output hint, use cases, and a necessary pagination warning. Each sentence earns its place, and the core purpose is front-loaded.

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?

Despite having no output schema, the description explains what the response will contain, how filtering and pagination work, and what edge cases to expect (e.g., small result sets from profitable_only). The tool is fully callable with the provided guidance.

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%, so all five parameters are already documented with meaningful descriptions. The description reinforces the roles of algorithm and profitable_only but does not add substantive new parameter meaning 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 first sentence immediately identifies a specific verb ('Paginated index') and resource ('Proof of Work networks BackPow tracks') plus the returned fields. It also differentiates from siblings by framing this as the catalogue/browsing tool, not a calculation, cost, benchmark, or news tool.

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 gives explicit use cases: find networks for an algorithm, browse the catalogue, or resolve an ambiguous coin reference. It does not explicitly name when not to use it or list sibling alternatives, but the context is clear enough that an agent can choose it appropriately.

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