SiteCheck Crypto & Finance

Bitcoin network hashrate with the last 3 daily averages

crypto_bitcoin_hashrate_difficulty

Read-only

Bitcoin network hashrate (EH/s) with the last 3 daily averages, current difficulty, difficulty-epoch progress and expected change, and miner revenue over the last 144 blocks (about one day): total reward incl. fees in BTC, fee share and average reward per block. Network-wide figures from mempool.space, not per-miner. Related tools on this server, for a different need: crypto_bitcoin_mempool_stats when you need Bitcoin mempool congestion from mempool.space: unconfirmed; crypto_kaspa_hashrate when you need Kaspa network hashrate current state, all-time peak. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "crypto_bitcoin_hashrate_difficulty"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`source`	No
`checkedAt`	No
`difficultyEpoch`	No
`currentDifficulty`	No
`currentHashrateEhs`	No
`dailyAvgHashrateEhs`	No
`minerRevenueLast144Blocks`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the description's added value is in data provenance (mempool.space), the scope boundary (network-wide, not per-miner), the 144-block ≈ one-day averaging window, and the billing model: $0.002 USDC per successful call via x402, failed calls free. What is missing is freshness/caching behavior — whether the figures are a snapshot or a trailing average of an unstated interval.

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

Conciseness4/5

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

Front-loaded with the resource and output inventory, and the pricing and sibling-routing information is placed after the core purpose. The first sentence is a long colon-separated enumeration that takes effort to parse, and the pricing sentence, while genuinely useful, sits inside a description that is already near a length ceiling.

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 zero parameters, an output schema present, and read-only annotations, the description only needs to establish scope, source, window, and cost — and it does all four. An agent can decide to call it and interpret the response without further information.

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

Parameters4/5

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

The input schema is an empty object, so there are no parameters to disambiguate; baseline is 4. The description correctly implies a parameterless fetch and spends no words on nonexistent inputs.

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?

Names the exact resource (Bitcoin network hashrate in EH/s) and enumerates the returned measures: 3 daily averages, current difficulty, difficulty-epoch progress and expected change, and 144-block miner revenue with fee share and per-block average. It also fixes scope as network-wide rather than per-miner, which removes ambiguity versus a pool-level tool.

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

Usage Guidelines4/5

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

Gives explicit routing for two conflicts: crypto_bitcoin_mempool_stats for mempool congestion and crypto_kaspa_hashrate for Kaspa hashrate, each with a stated condition. It does not address overlap with closely related Bitcoin siblings such as crypto_btc_mining_economics or crypto_btc_mining_pools, even though the miner-revenue portion of this output plausibly overlaps with them.

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

All SiteCheck Crypto & Finance tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?