Skip to main content
Glama
0xcWalter

BackPow MCP Server

by 0xcWalter
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Solo mining odds

calculate_solo_mining_odds
Read-onlyIdempotent

Compute your solo mining odds for any PoW coin: block-finding probability, mean time, cost, and percentile waiting times from live network data.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
coin_idYesCoin 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: several tickers are shared by multiple tracked chains (DGB by 5, XVG by 5, TARI by 4).
hashrateYesThe miner's rate, as a number. The unit goes in hashrate_unit.
power_wattsNoMiner power draw in watts, e.g. 3500 for an ASIC or 320 for a GPU. Optional.
hashrate_unitYesUnit 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_kwhNoElectricity price in USD per kWh. Defaults to 0.069, an industrial hosting tariff; residential rates are commonly 3-5x higher and change profitability conclusions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already establish this is read-only, idempotent, and non-destructive, so the bar for added value is met well. The description discloses the statistical model (Poisson process), live inputs, the specific computed outputs, and the caveat that variance dominates at small hashrates, making the average misleading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and output, then gives concrete use cases and sibling routing. Every sentence earns its place, including the variance caveat and alternative tool references, without unnecessary repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description adequately enumerates return values: mean time, probabilities over standard horizons, and percentile waiting times. It also covers when to use the tool, when not to, and what distinguishes it from related tools, making it complete for agent selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; the schema already thoroughly documents coin_id, hashrate, hashrate_unit, power_watts, and electricity_cost_usd_kwh. The description adds useful conceptual framing by connecting parameters to the Poisson model and electricity cost, but it does not add substantial syntax or format details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies a specific verb and resource: computing solo mining odds via a Poisson process over network difficulty and hashrate. It clearly distinguishes itself from siblings by naming get_cost_of_production and get_coin_oracle as alternatives for different questions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit example questions that should route to this tool, such as 'how long would it take to solo mine a Bitcoin block with 100 TH/s'. It also states exclusions: pooled mining economics or general profitability should use get_cost_of_production, and raw network state should use get_coin_oracle.

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

Deploy Server

Other Tools