Proof of Work oracle: solo mining odds, cost of production, hashrate, mining hardware
Scored across 6 tools
Each tool targets a clearly distinct question: odds, network state, production cost, hardware profitability, news, and coin index. Cross-references in descriptions actively prevent confusion between overlapping economics tools.
All tool names use snake_case with a verb prefix, mostly get_, plus calculate_ and list_ for actions that are not simple fetches. The pattern is predictable and uniform.
Six tools is a well-scoped size for a specialized PoW oracle. Each tool covers a distinct facet of mining data without redundancy or bloat.
The tool set covers the full apparent domain: network state, mining economics, hardware selection, solo mining probability, news, and coin discovery. No critical workflow appears to dead-end, and the descriptions route users to the right tool for each question.
Probability of a solo miner finding a block, computed as a Poisson process over live network difficulty and hashrate, plus the electricity cost of the attempt. Returns mean time to a block, the chance of at least one block over 1/7/30/90/365 days, and lucky-vs-unlucky waiting times (5th, 50th and 95th percentile) — variance dominates at small hashrates, so the average alone is misleading. Use for questions like "how long would it take to solo mine a Bitcoin block with 100 TH/s", "what are my odds solo mining Kaspa", or "is solo mining worth it with this rig". For pooled mining economics or whether a coin is profitable at all, use get_cost_of_production. For raw network state without a miner, use get_coin_oracle.
| Name | Required | Description | Default |
|---|---|---|---|
| coin_id | Yes | Coin name or ticker, e.g. "Bitcoin", "BTC", "Kaspa", "bitcoin cash", "Monero". Ambiguous input is rejected with the list of matching networks rather than resolved to a guess, because several tickers are shared by more than one tracked chain (DGB, XVG and TARI among them). | |
| hashrate | Yes | The miner's rate, as a number. The unit goes in hashrate_unit. | |
| power_watts | No | Miner power draw in watts, e.g. 3500 for an ASIC or 320 for a GPU. Optional. | |
| hashrate_unit | Yes | Unit for hashrate. Most networks measure in hashes per second (H/s…EH/s). Cuckoo-family chains measure graphs per second (gps) and Aleo measures proofs per second — an unrecognised unit is rejected rather than assumed, because assuming H/s can be wrong by a factor of 10^12. | |
| electricity_cost_usd_kwh | No | Electricity price in USD per kWh. Defaults to 0.069, an industrial hosting tariff; residential rates are commonly 3-5x higher and change profitability conclusions. |
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.
Current network state for one Proof of Work chain, measured by BackPow's stratum collector nodes: difficulty, derived network hashrate, block height, block reward, protocol block-time target versus the latest observed interval, and the source pool. Every response carries a confidence block — how many independent pool operators agreed, whether the reward figure is live or a static fallback, and how old the observation is. Networks whose collectors are stalled or unreachable return an error rather than zeros. Use for "what is Kaspa's current difficulty", "network hashrate of Monero", "current block reward". For economics use get_cost_of_production; for mining probability use calculate_solo_mining_odds.
| Name | Required | Description | Default |
|---|---|---|---|
| coin_id | Yes | Coin name or ticker, e.g. "Bitcoin", "BTC", "Kaspa", "bitcoin cash", "Monero". Ambiguous input is rejected with the list of matching networks rather than resolved to a guess, because several tickers are shared by more than one tracked chain (DGB, XVG and TARI among them). |
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.
Cost of Production (CoP) for one Proof of Work coin: the all-in electricity cost of mining one unit on the most efficient hardware BackPow tracks for that algorithm, compared against spot price. Returns CoP in USD, spot, gross margin, whether miners are currently above or below water, the reference machine and tariff behind the figure, and a 30-day trend including whether the reference machine changed (which indicates the efficiency frontier moved). Accepts a custom electricity rate. Use for "is mining X profitable", "what does it cost to produce one Monero", "are miners underwater", or "break-even electricity price". For a specific rig rather than a coin, use get_hardware_benchmarks. For block-finding probability, use calculate_solo_mining_odds.
| Name | Required | Description | Default |
|---|---|---|---|
| coin_id | Yes | Coin name or ticker, e.g. "Bitcoin", "BTC", "Kaspa", "bitcoin cash", "Monero". Ambiguous input is rejected with the list of matching networks rather than resolved to a guess, because several tickers are shared by more than one tracked chain (DGB, XVG and TARI among them). | |
| electricity_cost_usd_kwh | No | Electricity price in USD per kWh. Defaults to 0.069, an industrial hosting tariff; residential rates are commonly 3-5x higher and change profitability conclusions. |
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.
Mining hardware matched to the coins it can mine, ranked by net USD per day at a given electricity rate. Covers ASICs, GPUs and CPUs, with hashrate and power draw per coin, gross revenue, net profit, and market price including whether that price is an observed listing or a model estimate. Use for "what should I mine with an RTX 4090", "best ASIC for Scrypt", "is an Antminer S21 still profitable", or "how much does a Bitaxe make". Coins are ranked by profitability, not alphabetically, and results are capped — ask for a higher limit rather than assuming the list is complete. For a coin's economics independent of any particular rig, use get_cost_of_production.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Restrict to one hardware class. | |
| limit | No | Devices to return, 1-25. Defaults to 5. | |
| query | Yes | Hardware model or keyword, at least 2 characters, e.g. "RTX 4090", "Antminer S21", "Bitaxe", "Ryzen 9 7950X". Short or generic queries match hundreds of devices, so pair them with type and limit. | |
| coin_id | No | Restrict the per-device coin rows to one network, e.g. to answer "how much does this rig make on Kaspa". Optional. | |
| electricity_cost_usd_kwh | No | Electricity price in USD per kWh. Defaults to 0.069, an industrial hosting tariff; residential rates are commonly 3-5x higher and change profitability conclusions. |
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.
Recent news items about Proof of Work mining and network events, optionally filtered to one coin. Items are aggregated from third-party feeds and are returned as quoted external content with their publisher and a relevance score, not as BackPow statements of fact. Use when a question turns on recent events — a halving, a difficulty swing, a pool outage, a chain upgrade. For numbers rather than narrative, use get_coin_oracle or get_cost_of_production.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Items to return, 1-20. Defaults to 5. | |
| coin_id | No | Optional coin filter, e.g. "Bitcoin", "Zcash", "Kaspa". | |
| include_low_signal | No | Include items that relevance triage scored 0. Excluded by default so results stay on topic for Proof of Work mining. |
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.
Paginated index of the Proof of Work networks BackPow tracks, with algorithm, network rate, collector status and canonical page URL. Optionally filtered by algorithm or restricted to coins currently mining above cost. Returns the distinct algorithm list so valid filter values are discoverable. Use to find which networks exist for an algorithm, to browse the catalogue, or to resolve an ambiguous coin reference. Results are paginated: request a larger limit or a later offset rather than expecting the full catalogue in one response.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows to return, 1-100. Defaults to 25. | |
| offset | No | Rows to skip for pagination. Defaults to 0. | |
| sort_by | No | Ordering. "suffering" ranks by how far Cost of Production exceeds spot price. Defaults to name. | |
| algorithm | No | Case-insensitive substring filter on algorithm, e.g. "SHA-256", "Scrypt", "KawPow", "RandomX", "Autolykos". The response lists every algorithm present. | |
| profitable_only | No | Restrict to coins whose spot price currently exceeds Cost of Production. Profitability is resolved for the returned page only, and the response reports how many of those coins have CoP coverage, so a small result set can be distinguished from missing data. |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
calculate_solo_mining_oddsget_coin_oracleget_cost_of_productionget_hardware_benchmarksget_pow_newslist_pow_coinsLive GPU rental market: 2,500+ offers across a dozen provider feeds. History, watches, limit orders.
Deterministic crypto futures, on-chain risk, and prediction-market math. 31 tools. Not AI estimates.
Agent-native price and event oracle with cryptographic source attestation
TONOracle - 11 TON tools: jettons, Telegram payments, validators, smart contracts.
Add one secure layer between your agents and this server.
