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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no assumptions about network difficulty, block reward, pool fees, or BTC/USD input, no indication that it is a read-only computation, and no information about the returned value's units. For a tool with zero annotation coverage this is a notable gap.

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?

A single short sentence that front-loads the verb and the computed quantity with no filler. It is efficient, though its extreme brevity is partly why other dimensions are thin.

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?

The three required inputs are fully documented in the schema, but there is no output schema and the description does not clarify what the returned breakeven price represents or what underlying network assumptions are baked in. Given the absence of annotations and output schema, slightly more context would be warranted.

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 each of the three required parameters (hashrate_th, power_watts, electricity_cost) documented with units in the schema. The description adds nothing beyond that, 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?

The description names a specific verb (Calculate) and a specific resource (breakeven BTC price for a mining operation), so an agent can tell what it produces. It is distinguishable from pure data-fetch siblings like get_price_history or get_difficulty, but it does not contrast itself with the closest sibling, calculate_profitability.

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 statement of when to use this tool versus calculate_profitability or how to obtain the required inputs (e.g., whether hashrate/power must be user-supplied or can be inferred). The agent gets no context, prerequisites, or exclusions.

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 disclosure burden. It never states that this is a read-only computation, which network assumptions it uses (current difficulty, block reward, hashprice), or that results are estimates rather than live network data — all material for a profitability model.

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?

A single compact sentence with no filler and the core resource front-loaded. It is under-specified rather than bloated, so length is not the problem.

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 six parameters, no annotations, and no output schema, the description should say what the calculation returns (daily/monthly revenue, profit, breakeven days) and what network assumptions underpin it. Neither is present, so an agent cannot predict the result shape or trust boundary.

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 all six parameters including defaults for days, pool_fee_pct, and btc_price. The description names only hashrate and electricity_cost and omits the required power_watts, so it adds nothing beyond the schema; 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 ('Calculate mining profitability') with the two headline inputs, so an agent immediately knows the domain. It does not, however, distinguish itself from the closest sibling, calculate_breakeven, which also takes hashrate/cost inputs.

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 indication of when to pick this over calculate_breakeven or any of the data-retrieval siblings. No exclusions, prerequisites, or scenario cues are given, leaving the agent to infer selection from the name alone.

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 disclosure burden. It does not state that the call is read-only, whether the data is real-time or cached, what units the efficiency stats use (e.g., J/TH), or what timeframe is covered.

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?

A single short sentence with the resource front-loaded and zero filler. Nothing is wasted, though there is also very little 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?

For a no-parameter, no-output-schema tool the description needs only to convey what comes back, and 'price data and efficiency stats' is a reasonable minimum. It still leaves the shape and scope of 'efficiency stats' undefined, which matters for an agent choosing among the many sibling data tools.

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 tool takes zero parameters, so the baseline of 4 applies. There is no parameter documentation gap to compensate for, and the schema is empty as expected.

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 (ASIC miner price data and efficiency stats), which is more informative than the bare tool name. However, it offers no differentiation from siblings like get_hashprice or get_market_data that also return price-oriented data, so an agent must infer which one fits.

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 guidance on when to use this tool versus alternatives such as get_hashprice, get_market_data, or calculate_profitability, all of which appear related to miner economics. No preconditions or exclusions are stated.

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 behavioral burden. It implies a harmless zero-parameter read and reveals that a forward-looking prediction is included, but it says nothing about the prediction model, data source, or update cadence.

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?

A single front-loaded sentence containing both the primary result and the secondary prediction, with no filler or redundancy.

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 must carry return-value meaning. It names the two returned concepts but omits units, the estimated adjustment magnitude, and when the next adjustment occurs, leaving the agent to guess at the payload 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No parameter meaning is missing.

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 ('current difficulty') plus an extra output ('next adjustment prediction'), so the agent knows what it retrieves. It does not explicitly distinguish itself from the sibling get_difficulty_history, relying on the agent to infer current-vs-historical.

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 guidance, no condition distinguishing it from get_difficulty_history, and no mention of prerequisites or freshness. The agent must infer usage entirely from the name.

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 must carry the behavioral burden. It does not state default time range, output shape, pagination, rate limits, units, or whether results are aggregated, leaving key operational behavior undisclosed.

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 a single concise phrase and is front-loaded with the action and resource. It is appropriately short, though the brevity contributes to the missing guidance noted elsewhere.

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 historical-data tool with no annotations and no output schema, the description is too sparse. It omits default date behavior, result granularity, and distinctions from closely related sibling tools.

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 from/to parameters have clear YYYY-MM-DD descriptions, so the schema handles parameter semantics adequately. The description adds no additional parameter meaning or constraints 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?

The description gives a clear verb (Get) and resource (historical difficulty and hashrate data), so the basic purpose is understandable. However, with siblings like get_difficulty, get_hashprice, get_weekly_stats, and get_monthly_averages, it does not distinguish scope or granularity from these alternatives.

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 when-to-use guidance is provided. It does not explain when to choose this historical endpoint instead of get_difficulty, get_hashprice, or get_monthly_averages, nor does it mention default date behavior despite optional from/to parameters.

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 behavioral burden. It partially compensates by enumerating what is returned (current era, next halving date, supply stats), but says nothing about freshness/caching, units, rate limits, or response shape for a tool with no output schema.

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?

A single front-loaded line with the resource stated first and the returned fields listed after the dash. No filler sentences to trim.

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 read-only, zero-parameter tool with no annotations or output schema, the description is nearly sufficient because it enumerates the three data points returned. It stops short of describing format/units or data currency, which would be needed for full completeness.

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 tool takes zero parameters, so there are no parameter semantics to document; the baseline for a parameterless tool is 4. Nothing in the description misleads about inputs.

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 ('Bitcoin halving information') and then enumerates the concrete payload (current era, next halving date, supply stats). None of the sibling tools (get_difficulty, get_price_history, get_market_data, etc.) cover halving data, so an agent can route to it unambiguously.

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?

Usage is only implied: an agent should call it when halving/era/supply context is wanted. There is no explicit when-to-use, when-not-to-use, or named alternative, though no sibling overlaps this domain, so the cost of the omission is low.

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 carries the behavioral burden, and it does disclose that the value is current-snapshot and comes with a 'detailed breakdown'. It does not say whether data is cached, how fresh it is, or what the breakdown comprises, which is a gap for a read tool with zero annotation support.

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?

A single front-loaded sentence with no filler; the metric definition is parenthetical and tightly scoped. It could arguably be a touch more informative without losing brevity, but nothing is wasted.

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?

There is no output schema, so the description should ideally characterize the 'detailed breakdown' it promises — what fields or dimensions the agent will receive. As written, an agent knows what the number means but not what the payload looks like, leaving the return shape underspecified.

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 tool takes no parameters, so there is no schema semantics to add beyond; the baseline for a zero-parameter tool applies. The description uses the sentence space instead on defining the returned metric, which is reasonable.

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?

Specific verb ('Get') plus resource ('hashprice') with an inline definition of the metric and its unit (mining revenue per PH/day). It is distinguishable from siblings like get_market_data or calculate_profitability by domain specificity, though it never explicitly contrasts itself with them.

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 statement of when to use this versus related tools such as get_market_data or calculate_profitability, and no prerequisites or context. The 'current' qualifier hints at a now-focused snapshot but is not framed as guidance.

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 behavioral burden. 'Get' implies a read-only operation and the returned fields are listed, but there is no mention of caching/freshness, rate limits, or auth requirements for what is presumably a live external data fetch.

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?

A single front-loaded sentence that names the resource first and then lists contents; no filler or redundancy.

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 zero-parameter read tool with no output schema, the description adequately enumerates what comes back (price, hashprice, difficulty, network stats). The remaining gap is that it does not clarify the aggregation relationship with overlapping siblings.

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 has zero parameters with 100% coverage, and the base case for a no-argument tool is 4. Nothing about invocation needs further clarification.

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 (Get) and resource (current Bitcoin market and mining data) and enumerates the contents: price, hashprice, difficulty, network stats. It is clear, but it never distinguishes itself from siblings like get_hashprice and get_difficulty, which return overlapping subsets of the same 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?

The word 'current' implicitly signals a snapshot rather than history, weakly steering the agent away from get_price_history and get_difficulty_history. However, it never explains when to use this aggregate call versus the narrower get_hashprice/get_difficulty siblings that return the same fields.

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 restates the returned categories ('status and fee estimates') and implies a read via 'Get', but discloses nothing about data freshness, source, rate limits, or output characteristics.

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?

A single, front-loaded six-word sentence with no filler. Every word earns its place for a low-complexity read operation.

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 annotations and no output schema, the description should ideally indicate return shape or key metrics. It names two data categories but leaves units and structure unspecified, making it minimally viable but incomplete for an agent that must interpret the response.

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 tool has zero parameters, so there are no parameter semantics to document. Baseline 4 applies because the schema is empty and no additional parameter meaning is needed.

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 the resources 'mempool status' and 'fee estimates'. Clear enough to distinguish from sibling tools, none of which cover mempool data, but it does not explicitly differentiate beyond the unique resource name.

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 when-to-use guidance, no alternatives, and no exclusions are provided. The description only implies the tool is for mempool and fee data, leaving all selection context 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the UTC aggregation convention and the precondition that the month be complete, but says nothing about error behavior for incomplete months, permissions, or response shape.

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 tight sentences with no filler; the resource and metrics lead, and the completeness constraint closes. Every clause adds 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?

For a simple one-parameter tool with no output schema, the description compensates well by naming the returned metrics and units in place of a return-value spec. Only the absence of annotations leaves a minor gap around error/precondition handling.

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 single parameter is fully documented there, including a format example, so the baseline of 3 applies. The description's "(UTC)" adds only marginal clarification about timezone of aggregation beyond the schema's own month format.

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 (calendar-month averages) and enumerates the exact metrics returned — BTC price, network hashrate, hashprice — with their units (USD and BTC). This clearly separates it from aggregation siblings like get_weekly_stats, though no sibling is named explicitly, so it falls just short of a 5.

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?

"For monthly mining reports" supplies a clear use context, and "The month must be complete" is an effective implicit exclusion (no current/partial months). It stops short of naming an alternative such as get_weekly_stats or get_price_history for finer-grained data.

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 behavioral burden, yet it says nothing about read-only semantics, the default granularity of "day", date-range behavior when from/to are omitted, or what the returned series looks like. For an unannotated data tool this is a real gap.

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?

A single front-loaded sentence with zero filler, which is efficient. It is arguably too terse for the information an agent needs, but the sentence itself is well-formed and wastes nothing.

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 annotations and no output schema, the description should at least state defaults and the relationship to get_monthly_averages/get_market_data. It omits both, leaving the agent to infer scope and behavior from the schema alone.

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 the schema already documents from, to, and granularity (including the enum and the get_monthly_averages pointer). The description adds no parameter meaning beyond that, 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?

"Get historical Bitcoin prices" names a specific verb and resource, so the agent knows this retrieves time-series price data. However, it does not differentiate from siblings that also return price/market data, such as get_market_data or get_monthly_averages.

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 guidance on when to use this tool versus get_market_data, get_monthly_averages, or get_hashprice. The only routing hint ("use get_monthly_averages for calendar-month averages") lives in the schema, not the description.

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 disclosure burden. It does usefully convey the temporal scope ('a few hours') and the 50-block ceiling, but says nothing about read-only nature (only implied by 'get'), pagination, or what a returned block looks like.

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 tight sentences with no filler; the primary capability is front-loaded and the routing hint follows immediately after.

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 zero-required-parameter read tool with full schema coverage and no output schema, the description supplies the scope, time span, and the key alternative. Nothing critical is missing, though return shape and error/limit behavior remain unaddressed.

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 already documents the limit parameter with its default and max, so the baseline is 3. The description earns a bump by contextualizing what a limit of 50 means in time ('a few hours'), which the schema does not convey.

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 Bitcoin blocks) with an explicit scope bound of max 50 / a few hours. It distinguishes itself from get_weekly_stats, but does not differentiate from other siblings like get_difficulty or get_mempool, so it stops short of a 5.

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?

Gives an explicit alternative for adjacent needs: 'For weekly block time, fees or hashprice use get_weekly_stats.' That is clear routing guidance, though it offers no when-not condition for the tool itself and no prerequisites.

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 carries the full burden and does well: it defines the ISO week (Monday 00:00 UTC to Monday 00:00 UTC), specifies closed weeks only (no partial/in-progress data), and states the default span. It stops short of describing response shape limits, error conditions, or rate limits, but the temporal semantics are unusually well disclosed.

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 verb, resource, and the precise temporal scope before the long field enumeration. The output list is dense but each item is informative; the only cost is that the single sentence becomes long, but nothing is redundant.

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, the description compensates by enumerating returned content (block count, avg block time, fees, hashrate, hashprice in BTC/USD, difficulty adjustments, raw daily rows, methodology) and the default window. An agent knows what it gets and how the week is bounded; only edge cases and limits are unaddressed.

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%, so both parameters are already documented, including the max of 8 weeks. The description adds the default span ('last 2 closed weeks') which reinforces the schema but adds no syntax or format detail beyond it — the baseline 3 for fully-covered schemas.

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+resource with tight scope: closed ISO-week Bitcoin network stats, with the exact week boundary defined. The output list (fees, hashrate, hashprice, difficulty adjustments, BTC price) makes it clearly distinguishable from siblings like get_monthly_averages, get_price_history, and get_hashprice.

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?

Gives context ('for weekly mining reports') and states the default window (last 2 closed weeks), which implies when it applies. However, it never says when to prefer this over get_monthly_averages or get_price_history, and offers no exclusions or prerequisites, leaving routing to inference.

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