Skip to content

Latest commit

 

History

History
438 lines (365 loc) · 27.7 KB

API.md

File metadata and controls

438 lines (365 loc) · 27.7 KB

bumblebeam pool: HTTP API

The contract between the pool server and its web UI (pool/web). All responses are JSON and all endpoints are GET. Nothing public links an address to a hashrate or a balance (see /api/miners). Amounts are in groth (1 BEAM = 10⁸ groth) as integers, hashrates in Sol/s, times in unix seconds, and effort is a ratio (1.0 = average luck). CORS is open (*). The UI treats every field as untrusted: numbers are coerced, strings are length-capped and escaped before they reach the page, so a field with HTML in it is shown as text, never rendered.

GET /api/stats?range=24h&mode=

The pool at a glance. The top-level fields follow the open-ethereum-pool shape, so the Beam Explorer's existing open-eth adapter (BeamMW/BeamExplorer, backend/src/mining/adapters.ts) reads the pool with no code change: hashrate, minersTotal, workersTotal, stats.lastBlockFound and nodes[0].height. The config block adds the fee and payout data that 2Miners' API does not expose.

{
  "hashrate": 5230.4, "minersTotal": 41, "workersTotal": 97,
  "stats": { "lastBlockFound": 1791321278, "roundShares": 10342912 },
  "nodes": [{ "name": "beam-node-1", "height": "4068710", "difficulty": "2719891.5",
              "networkhashps": "45570", "lastBeat": "1791321596" }],
  "config": { "fee": 0.5, "soloFee": 0.5, "finderBonus": 1.0, "minPayout": 10000000, "payoutScheme": "PPLNS",
              "pplnsWindow": 2.0, "blockReward": 2500000000, "maturity": 240, "payoutInterval": 7200 },
  "charts": { "hashrate": [[1791300000, 5120.0], [1791300600, 5301.2]], "peak": [1791300420, 6890.4] },
  "modes": {
    "pplns": { "hashrate": 5180.2, "miners": 39, "workers": 94, "blocks24h": 30, "lastBlockFound": 1791321278,
               "series": [[1791234000, 5011.7]] },
    "solo":  { "hashrate": 50.2, "miners": 2, "workers": 3, "blocks24h": 1, "lastBlockFound": 1791290000,
               "series": [[1791234000, 48.1]] }
  },
  "blocks24h": 31, "effort24h": 0.94, "blocksPending": 12
}
  • blocksPending counts every block still waiting for maturity or an operator's verdict (pending and unverified), not just those on one page of /api/blocks.

  • name is the pool's display name. config.stratumHost and config.ports (pplns, solo, pplnsTls, soloTls) tell the UI where miners connect, config.nodeAddr (host:port, empty if not offered) where wallets can reach the pool's node; connectedWorkers counts open stratum connections; nodes[0].connected says whether the pool currently has a block template from its node.

  • fee and soloFee are percentages. The pool's fee is 0.5% on both PPLNS and solo rewards.

  • finderBonus is the percentage of a PPLNS block, after the fee, credited to the miner whose share found it, on top of that miner's PPLNS part; the rest of the pot is shared as usual. It is written as a separate credit for the block. 0 means no bonus; solo already pays the finder the whole block.

  • minerPaysTxFee and txFee: Beam's network fee comes out of each payout. A payout to an offline, max-privacy or public-offline address is a shielded transaction and costs about 0.01 BEAM; to a regular address about 0.00001 BEAM. The wallet is asked for the exact fee (calc_change) at payout time; txFee holds the fallbacks. This is why minPayout defaults to 1 BEAM.

  • blockFeesTo: the transaction fees inside a found block go to the pool, not into PPLNS; they are recorded per block (fees) for transparency. The coinbase holds the reward plus the fees, so fees is known once the wallet confirms the block and is 0 until then.

  • blockReward is the miner reward at the current height from the core's emission rule (80 BEAM in year one, then 40, 25 today, 12.5 from height 4,730,400, halving every 2,102,400 blocks). When the field is missing the UI derives it from nodes[0].height with the same rule.

  • effort24h is the average effort of the blocks found in the last 24 hours (shares spent / expected). It replaces the inverse "luck" figure: one direction, below 1.0 is good luck.

  • payoutInterval is the seconds between payout runs.

  • charts.hashrate is [unix seconds, Sol/s] pairs. ?range=24h (default), 7d or 30d picks the span: one point per minute, per hour or per four hours, each the average over its interval. Samples are kept for 31 days. ?mode=pplns or ?mode=solo draws one mode's hashrate; without it the chart is both together.

  • charts.peak is the range's highest one-minute hashrate, [unix seconds, Sol/s] (null without data). The 7d and 30d points are hourly and four-hourly averages, which flatten a short peak; this one is not, so the week's peak is never below the day's.

  • modes splits the pool into its PPLNS side and its solo side, as two pools: hashrate, miners and workers over the last 10 minutes, blocks in 24 hours, the last block, and series, hourly averages over 24 hours for a sparkline.

GET /api/blocks?limit=50&before=<height>

The blocks the pool found, newest first; before pages further back. status is pending (fewer than maturity confirmations), confirmed, orphaned, or unverified. A block is confirmed when its coinbase is in the pool wallet, or, if the wallet is not consulted, when the explorer shows our hash at that height (verifiedBy: wallet, explorer, wallet+explorer). A block the chain replaced is orphaned. A block that is on the chain but whose coinbase the wallet cannot see, or about which the wallet and the chain disagree, is unverified: it is neither paid nor dropped until an operator decides (admin block <height> confirm|orphan). Only the wallet's coinbase can confirm a block; the explorer alone never does.

{ "blocks": [{ "height": 4068700, "hash": "…", "ts": 1791320000, "reward": 2500000000,
               "fees": 1100000, "effort": 0.82, "status": "pending", "confirmations": 10,
               "finder": "rig1", "mode": "pplns" }],
  "matured": [], "immature": [{ "height": 4068700, "…": "…" }], "candidates": [] }

matured (confirmed), immature (pending and unverified) and an always-empty candidates repeat the same page of blocks in the open-ethereum-pool shape, so the Beam Explorer's open-eth adapter credits our blocks to the pool. Orphaned blocks appear only in blocks.

GET /api/blocks/heights

Every block the pool found that the chain kept (orphans left out), newest first, as [height, mode, status] and nothing else, so a client can mark all of the pool's blocks with one small request. The Beam Explorer and explorer.bumblebeam.org use it to badge our blocks.

{ "count": 2, "blocks": [[4072327, "pplns", "pending"], [4071981, "pplns", "confirmed"]] }

GET /api/blocks/<height>?address=

One block the pool found and how its reward was split, so anyone can recompute every credit. The site shows it at /blocks/<height> and checks the arithmetic in the browser. Credits carry no address; address=<a> marks that miner's rows with "you": true. 404 for a height the pool did not find, 400 for one that is not a number.

{
  "height": 4068500, "hash": "…", "ts": 1791675000, "mode": "pplns", "status": "confirmed",
  "reward": 2500000000, "fees": 0, "effort": 0.91, "netDifficulty": 2977786.1, "recorded": true,
  "feePercent": 0.5, "finderBonusPercent": 1.0, "window": 5955572.2, "total": 5955601.0,
  "pot": 2487500000.0, "finderBonus": 24875000, "shared": 2462625000.0,
  "credits": [
    { "kind": "share", "difficulty": 3972064.0, "amount": 1642437783, "you": true },
    { "kind": "share", "difficulty": 1983537.0, "amount": 820187216 },
    { "kind": "bonus", "difficulty": null, "amount": 24875000 }
  ]
}
  • window is pplnsWindow × the block's network difficulty: the shares counted, newest first, back from the block. total is the difficulty actually taken: a little over window because the share that crosses the line counts whole, or under it while the pool has not yet mined a full window.
  • pot = reward × (1 − feePercent/100); finderBonus = floor(pot × finderBonusPercent/100), credited to the rig whose share found the block; shared = pot − finderBonus.
  • Each share row: amount = floor(shared × difficulty / total). Rows add up to at most pot; the rounding dust stays with the pool, as do the block's transaction fees.
  • A solo block has one solo row, floor(reward × (1 − feePercent/100)), and no window.
  • recorded: false: credited before rounds were kept (schema 7, 2026-10-11). The amounts are listed, difficulty, window, total and the percentages are null.
  • status is the block's: credits reach balances only once it is confirmed; an orphaned block's credits are never paid.

GET /api/miners?limit=50&mode=

Miners by current hashrate, without addresses. Beam is a private chain and the pool keeps it that way: nothing in the public API links a hashrate to a wallet. A miner's own page is reachable only through /api/miners/<address>, and offline addresses are long enough that they cannot be guessed.

{ "miners": [{ "hashrate": 52.1, "hashrate24h": 50.7, "workers": 2, "lastShare": 1791321590, "modes": ["pplns"] }] }

modes lists the modes the miner sent shares in over the last 10 minutes (pplns, solo, or both). ?mode=pplns or ?mode=solo keeps only that mode's miners, with that mode's hashrate.

GET /api/miners/<address>?range=24h&mode=

{ "address": "…", "hashrate": 52.1, "hashrate24h": 50.7, "balance": 812345678,
  "immature": 125000000, "paid": 12500000000, "sending": 0, "lastShare": 1791321590,
  "workers": [{ "name": "rig1", "hashrate": 52.1, "hashrate24h": 50.7, "lastShare": 1791321590,
                "online": true, "stale": 0.012, "rejected": 0.001, "modes": ["pplns"] }],
  "charts": { "hashrate": [[1791300000, 49.8]], "peak": [1791300060, 61.2] },
  "payments": [{ "ts": 1791300000, "amount": 1000000000, "kernel": "…" }],
  "addressType": "offline", "coinbase": null }

paid is what reached the miner's wallet; sending is sent and not confirmed yet (a payout the wallet gives up on goes back to balance).

addressType is regular, offline, max_privacy, public_offline or coinbase; coinbase is set only for cb: accounts (see coinbase payouts).

charts.hashrate takes ?range= as in /api/stats; minutes without shares count as zero. ?mode=pplns or ?mode=solo narrows hashrate, hashrate24h, workers and the chart to that mode's shares; balances and payments are the miner's whole account either way. modes lists the modes the miner mined in over 24 hours. blocksFound and blocks24h count the blocks this miner's shares found (orphans not counted), lastBlockAt is the latest one's time, and blocks lists the 10 most recent in the /api/blocks shape, orphans included. stale and rejected are the worker's share of stale and rejected shares over 24 hours, counted by the stratum server per connection and flushed once a minute. A stale share is one for a block that was already found when it arrived; it is not credited. The stratum server tells the miner why a share was rejected, using the oracle's own error names (collision, duplicate index, index order, nonzero result, difficulty not reached), so a miner can tell a broken kernel from a slow connection.

?worker=<name>&since=<unix seconds> adds blocksSince: the blocks that worker of this miner found since then, orphans not counted. The Mac miner app uses it for its per-session count, which the 10 latest blocks cannot always give.

GET /api/benchmarks and POST /api/benchmarks

Speed reports from the BumbleBeam Miner Mac app, sent only when its user turns on "Share average speed" (off by default). A report carries the machine and the speed, never an address; the IP is used only to allow one report per 10 minutes and is not stored.

{ "app": "0.2.0", "os": "macOS 26.7.1", "arch": "arm64", "model": "Mac17,1", "chip": "Apple M5 Pro",
  "gpuCores": 16, "cpuThreads": 15, "device": "gpu", "power": 80, "solPerSec": 8.6,
  "gpuWatts": 17.5, "minutes": 30 }

device is gpu or cpu, power the app's slider (1-100), solPerSec the average over minutes of mining, gpuWatts the miner's share of the GPU's draw when known. Text fields are printable ASCII up to 64 characters. Answers: 200 { "ok": true }, 400 with the reason, 429 for a second report within 10 minutes. GET returns the last 90 days grouped by chip, device and power: { "benchmarks": [{ "chip", "device", "power", "reports", "avg", "best", "gpuWatts" }] }.

GET /api/payments?limit=50

Pool payouts, newest first, one row per payout run: { "payments": [{ "ts", "amount", "miners", "kernel", "status", "txs": [{ "kernel", "amount" }] }] }. Beam pays each miner in its own transaction, so a run has one per miner: txs lists all of them, with the amount and without the address; a confirmed one has its kernel, to look it up on the chain, and one still confirming has "kernel": null. kernel is the latest, kept for older clients. A miner's own page lists the kernel of each payment to them. Failed payments are refunded to the balance and not listed.

GET /api/health

{ "ok": true, "node": true, "jobAgeSecs": 12, "uptime": 86400, "workers": 41 }. node is false while the pool has no block template, for example while the node syncs.

GET /api/network

The network as the pool page shows it, cached by the pool server for 30 seconds for all visitors. height, difficulty, avgBlock (seconds, over the last 60 blocks) and blocks24h come from an explorer-node, the pool's own first (pool.explorer_urls); priceUsd is BEAM's price in USD, the median of Beam's on-chain price oracle (Oracle2) from the same node, refreshed every 5 minutes.

pools, which the chain does not know: each pool's own API where it has a public one (2Miners, 2Miners Solo, HeroMiners, SunPool) for hashrate, miners, workers and lastTs, BumbleBeam from its own shares and blocks, the Beam Terminal's list for the rest and for series. A pool's blocks24h is counted from its own block lists (see /api/network/blocks) once the pool server has followed that pool for a whole day without a gap; until then it is the terminal's (SunPool reports its own), and without that either, the pool's rate over the hours already followed scaled to a day, with those hours in blocks24hHours (absent on a counted figure). HeroMiners' row counts its solo miners too, as ours does. Each part keeps its last good value while its source is down; a pool whose API does not answer shows the terminal's numbers.

hashrate is the network now, in Sol/s: the pools' current figures, which they measure from thousands of shares, over the part of the network they cover. The rest, othersHashrate and othersBlocks24h (solo nodes, pools with no API), can only be seen in its blocks, so its part is its share of the 24 h of blocks: hashrate = sum of pools / (1 - othersBlocks24h / blocks24h). chainHashrate is the chain's own estimate, the difficulty of the last 24 h of blocks over their time; hashrate falls back to it while an active pool's blocks are unknown. An hour of blocks is ±13% on luck alone, too few for a current figure. The UI falls back to the explorer directly when this endpoint is absent.

{ "hashrate": 61920.4, "chainHashrate": 53480.1, "othersHashrate": 10860.2, "othersBlocks24h": 243,
  "height": 4077447, "difficulty": 3210000.0, "avgBlock": 74.8, "blocks24h": 1382, "priceUsd": 0.0098,
  "pools": [{ "id": "2miners", "name": "2Miners", "website": "https://beam.2miners.com", "scheme": "PPLNS",
              "fee": 1, "hashrate": 31460.0, "miners": 88, "workers": 282, "blocks24h": 838,
              "lastTs": 1791845143, "series": [[1791840000, 31500.5]] }] }

GET /api/network/blocks

The latest blocks of the chain (up to 500, newest first) from the pool's explorer-node, each with the pool that found it, refreshed every 30 seconds. Who found a block: each listed pool's own API names its latest blocks with their hashes (2Miners and 2Miners Solo: /api/blocks; HeroMiners: /api/stats; SunPool: its miningpoolstats report, heights only), checked against the node's hash at that height, so an orphan is never credited; BumbleBeam's from its own database. The Beam Terminal's block list only fills a height no pool claims. pool and poolName are null for a block no listed pool claims (solo miners, private pools).

Parameters: limit (1-500, default 50), before=<height> (only blocks below it), pool=<id> (only that pool's, e.g. 2miners, herominers, bumblebeam).

{ "count": 2, "blocks": [
  { "height": 4082320, "hash": "aade819a…", "ts": 1792137956, "difficulty": 3123207.0, "pool": "2miners", "poolName": "2Miners" },
  { "height": 4082319, "hash": "5c01e2b4…", "ts": 1792137901, "difficulty": 3130014.0, "pool": null, "poolName": null } ] }

GET /api/miningboard

The pool in MiningBoard's miningboard-pool-v1 format (spec), which the directory polls every 5 minutes. Hashrates are in Sol/s, Beam's unit, and amounts are in BEAM, not groth. network is null while the pool has no block template.

{ "spec": "miningboard-pool-v1", "coin": "BEAM", "algorithm": "BeamHash III", "updated_at": "2026-10-08T03:10:00Z",
  "pool": { "hashrate": 46.6, "miners": 1, "workers": 2, "blocks_24h": 0, "last_block_at": null,
            "fee_percent": 0.5, "payout_scheme": "PPLNS", "min_payout": 1.0 },
  "network": { "hashrate": 52786.0, "height": 4070449, "difficulty": 2926199.5, "block_reward": 25.0, "block_time": 60 },
  "stratum": [{ "url": "stratum+tcp://stratum.bumblebeam.org:3333", "tls": false, "mode": "PPLNS" }] }

Payout addresses

Beam transactions are interactive. A regular wallet address expires (24 hours by default) and needs the receiving wallet online while the payout is built, so payouts to it fail whenever the miner's wallet is closed. The pool therefore asks for an offline address (also called a permanent or public offline address), which any Beam wallet can generate under "Receive". A regular address is accepted at login with a warning in the login response. Balances belong to the address that mined them: a payout to a regular address is attempted each run, a failed one is refunded to that balance and tried again next run, and the miner's page shows the address type. To move to an offline address, mine with it; the old balance is paid once its wallet is online.

Coinbase payouts

With [coinbase] enabled = true (see tools/coinbase/), a miner can be paid in the blocks the pool finds instead of by transactions. The miner's account is cb: plus a public key the bb-coinbase tool derives from the wallet's miner key (66 hex characters, ending in 00 or 01); it is the stratum login in place of an address. The miner uploads pairs, coinbase outputs with their kernels made and signed with its own keys; the pool verifies them through bb-finalizer and keeps them in stock; when the node asks for a block's coinbase, the pool picks pairs for what each account is owed (its balance, the credits of its blocks still confirming, and its share of this block), and the block pays them. The pool never holds the miner's keys, so it cannot spend these outputs. Blocks are then confirmed by the pool's own node, as the finalizer reports the chain (verifiedBy: "node").

GET /api/coinbase

{ "enabled": true, "height": 4070449, "domain": "pool.bumblebeam.org",
  "ladder": { "shift": 20, "steps": 12, "unit": 1048576 },
  "maxPairsPerUpload": 256, "stockMaxPerAccount": 512, "kernelValidityBlocks": 43200, "expiryMarginBlocks": 100,
  "maxCoinbaseBytes": 65536, "accounts": 3, "stockPairs": 96, "minedPairs": 240,
  "finalizer": { "connected": true, "tip": 4070449, "scanned": 4070449, "lastFinalization": 1791428210, "lastMined": 1791428210, "finalizations": 1312,
                 "failStreak": 0, "poolOnlyUntil": null } }

Pair values are unit × 2^k groth for k < steps (0.0105 … 21.47 BEAM); the stock is topped up with bb-coinbase top-up. A pair's kernel is valid for kernelValidityBlocks after its minimum height, and the pool stops offering it expiryMarginBlocks before that.

POST /api/coinbase/pairs, body { "account": "cb:…", "ts": <unix seconds>, "pairs": ["<hex>", …], "signature": "<hex>" } (bb-coinbase sends it). The signature is over domain (from GET /api/coinbase, so it cannot be replayed to another pool), the account, ts and the pairs, by the account key. Answer:

{ "account": "cb:…", "accepted": 34, "rejected": [{ "index": 2, "error": "invalid kernel signature" }],
  "stockPairs": 70, "validUntil": 4113649 }

Errors come as { "error": "…" } with 400 (shape, signature, ladder, expiry), 409 (stock full), 429 (uploads are verified one at a time, a second apart: try again), 503 (finalizer offline, or no block template yet). The miner page of a cb: account carries a coinbase object:

"coinbase": { "stock": [{ "value": 1048576, "count": 3 }], "stockPairs": 36, "stockValue": 12881756160,
              "minedPairs": 108, "minedValue": 38645268480, "blocks": 4, "expiredPairs": 0, "expiresAt": 4113649,
              "spentElsewhere": 0 }

and its payments have kernel of the form coinbase@<height> <block hash>: one payment per block and account. Its debit leaves the balance the moment the pool's node has the block, so the next blocks do not pay the same amount again; the payment is pending until the block confirms, then completed; if the block is orphaned it is failed, the debit is refunded and the pairs are back in stock. A balance can therefore be negative for a while (a block that had paid was orphaned): the next blocks work the advance off first, and a miner who leaves right after an orphan keeps at most that one block's share. A block the pool's node has already replaced (its header differs) no longer counts among the credits owed, so a reorg is felt at once, not 240 blocks later.

finalizer.failStreak counts coinbases with pairs the node refused in a row (it drops the finalizer on each); from two, the finalizer answers pool-only coinbases until poolOnlyUntil and logs an error: check --mine_online_reserve against max_coinbase_bytes. spentElsewhere counts pairs whose kernel turned up in a block that is not the pool's (another pool on the same chain, or the miner spending its own pair): they are simply gone from the stock, no payment is made. Such an account has no address, so the regular payout run skips it, and GET /api/payments lists transactions only, not these block payments. Solo logins are refused while coinbase payouts are on: every template already pays the PPLNS accounts.

Payment states

Each payment gets a transaction id chosen by the pool before anything is sent. created: the miner is debited and the id recorded; pending: the wallet accepted tx_send with that id; completed: the kernel id is known; failed: the wallet refused or the transaction failed, the debit is back on the balance; review: the wallet keeps failing to answer about the id, an operator decides; sending: a resend is in flight. A created payment left by a crash or a timeout is first looked up with tx_status; if the wallet does not know it, it is sent again with the same id, but only once admin probe-txid has proven that the wallet refuses a second send with the same id (stored in meta.txid_honored); until then such payments go to review. Money is refunded only when the wallet refuses and does not know the id.

Stratum ports

Port Mode TLS
3333 PPLNS no
3334 SOLO no
3443 PPLNS yes
3444 SOLO yes

The login is <wallet address>.<worker name>, and every Beam miner speaks the protocol unchanged: Beam's own stratum dialect from pow/stratum.h in the core. lolMiner and GMiner default to TLS for Beam, so the TLS ports are the ones most miners land on; the certificate is self-signed and miners do not verify it. Share difficulty is per worker (vardiff), aimed at about one share every ten seconds, starting at 64. A rig that will not work below its own minimum (rented ones on MiningRigRentals) asks for it after the worker name, <wallet address>.<worker name>+8192: the difficulty starts there and vardiff does not go below it; the worker keeps its name without the suffix. The pool assigns each connection a nonce prefix so no two rigs search the same nonces. The server is pool/server (Rust).

Operator's API

/api/admin/* backs the operator's dashboard at /admin. It exists only when [admin] token is set in pool.toml (24+ characters), takes Authorization: Bearer <token>, answers with Cache-Control: no-store and has no CORS headers. A wrong token is logged with the client's address; every action is logged.

GET attention unverified blocks, blocks orphaned in the last 7 days (no action needed), payments in review or stuck, miners whose payouts are held, txId deduplication proof
GET wallet the wallet's available, maturing, sending and receiving (or why it did not answer), what the miners are owed (unpaid balances, immature credits, payouts on the way) and what the pool earned in 24 h, 7 days and in all (confirmed blocks less the miners' credits, less network fees the pool paid)
GET connections live stratum connections (peer, port, TLS, address, worker, agent, difficulty, shares) and the last 300 that ended before a login, with what they sent first and why they ended
POST connections/<id>/kick ends a connection
GET miners?q=&limit= miners, most recently active first, filtered by a piece of the address
GET miners/<id> one miner: workers over 7 days, block credits, payments, live connections, held ({at, note} or null)
POST miners/<id>/hold {"hold": true, "note": "…"} or {"hold": false} holds one miner's payouts or releases them: held, no run pays it, scheduled or the operator's, while it still mines and is credited; a payout already sent goes on; a move (merge) takes the hold along; not for coinbase accounts (paid in blocks)
POST miners/<id>/merge {"to": "<address>"} moves shares, credits, found blocks and unpaid balance to another miner of this pool, never to a new address (ends the miner's connections first)
POST blocks/<height> {"action": "confirm"|"orphan", "force": false} as admin block
POST payments/<txid> {"action": "sent"|"refund", "force": false} as admin payment
POST payouts {} or {"miner": <id>} a payout run now, done by the payout loop and answered with a line per miner: everyone at the threshold, or one miner's whole balance even below it

MCP for agents

https://pool.bumblebeam.org/mcp is the pool's MCP server (Streamable HTTP, stateless, read-only):

tool what it answers
pool_stats pool hashrate, miners, workers, blocks in 24h, effort, fee, PPLNS and solo split, chart and its peak; mode for one mode's chart
pool_blocks blocks the pool found, with status and finder
pool_block_round how one block was split: fee, finder bonus, PPLNS window, every credit; address marks a miner's rows
pool_miner one miner by payout address: hashrate and its peak, balances, workers and their modes, payments, blocks
pool_miners top miners by hashrate with their modes; mode for PPLNS or solo only
pool_payments payout runs
pool_network Beam network (from the chain), BEAM/USD, every Beam pool
pool_network_blocks the latest network blocks with the pool that found each, pool to filter
pool_health whether the pool is up and has work
claude mcp add --transport http bumblebeam-pool https://pool.bumblebeam.org/mcp

The blockchain itself (blocks, kernels, assets, contracts) is in the explorer's MCP server, https://explorer.bumblebeam.org/mcp, described in explorer/API.md.