Loading ToolBench
50 Bitcoin tools for AI agents using Bitcoin Core or a compatible API backend. Query and analyze the Bitcoin network. Uses a local Bitcoin Core/Knots node or a compatible API configured with SATOSHI_API_URL. Provides mempool analysis, fee estimation, block inspection, transaction decoding with inscription detection, and mining insights.
The Bitcoin MCP server provides 20 well-named tools with consistent verb_noun naming (get_*, analyze_*, estimate_*, check_*). All tools have descriptions in the 50-150 character range, meeting the guideline that descriptions should be 10-1024 characters. However, critical gaps exist: (1) Input schemas are partially incomplete, while most tools declare parameter types (integer, string, number), several lack formal JSON Schema structures with detailed constraints; (2) Parameter descriptions are minimal or absent in the visible schema definitions; (3) Output schemas are not documented in the source code, forcing LLMs to guess what fields are returned; (4) Error handling patterns are not visible in the tool definitions. The tool naming is strong (get_node_status, analyze_block, estimate_transaction_cost, etc.), but parameter documentation and response structures are underdeveloped. The server demonstrates solid domain coverage for Bitcoin operations but falls short of A-grade quality due to incomplete schema documentation.
Analyze a block: header details, transaction count, fee stats, miner identification, SegWit/Taproot adoption percentage.
Full mempool analysis — depth, fee tiers, congestion score.
Analyze the next block template with pending transactions.
Full transaction decode with input/output breakdown, fee analysis, inscription detection, OP_RETURN data parsing, and confirmation status.
Check whether a specific output is spent or unspent.
Side-by-side comparison of two blocks.
Side-by-side comparison of fee sources.
Output schemas not documented. The source code does not declare what fields each tool returns, forcing LLMs to guess response structure and complicating chaining of tools. This violates the pattern:tool requirement that response schemas must be documented.
Parameter descriptions are minimal or absent in the visible schema definitions. Tools like get_node_status and get_block_count declare empty input objects {}, but most other tools lack detailed descriptions of what each parameter controls, valid ranges, or format constraints. This violates pattern:tool-description.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 23 | - | v1 |
Human-readable decode of a raw transaction hex.
Estimate the exact cost in sats and USD for a transaction given inputs, outputs, and fee rate.
Plain-English explanation of a Bitcoin script.
Get the current block count/height of the blockchain.
Get statistical breakdown of a block with percentiles.
Get optimal fee rate, urgency tiers, and fee recommendations.
Get ancestor chain for a transaction showing CPFP fee-bumping opportunities.
Get details for a specific unconfirmed transaction in the mempool.
Get raw mempool stats — size, bytes, min fee floor.
Get network info: protocol version, relay fee, connections, warnings. In hosted API mode, reflects the API server's network view.
Get Bitcoin network status: chain, height, sync progress, disk usage, connections, version. In hosted API mode, reflects the API server's node.
Get connected peer details: addresses, latency, services, version. In hosted API mode, shows the API server's peers.
Summary of a block range.
Input schema format is minimal. While parameter types are declared (integer, string, number), there are no min/max bounds, enum constraints, regex patterns, or detailed descriptions in the schema itself. For example, analyze_block takes height (integer) with only a short description, no minimum value (0), maximum (current block height), or format note.
No error handling guidance visible in tool definitions. The source code does not show error responses, recovery suggestions, or actionable error messages. If a tool fails (e.g., invalid block height, unreachable RPC endpoint), the LLM has no guidance on what to try next.
No pagination or result-limiting patterns visible. Tools that could return large result sets (analyze_mempool, analyze_next_block, search_blocks, get_mempool_ancestors) lack page/limit/offset parameters or documentation of result caps. This risks context window exhaustion if the API returns thousands of items.
Tool composition broken for some workflows. Tools return data structures (e.g., analyze_transaction returns transaction details) but it is unclear what fields are included or whether they supply IDs needed for downstream tools. If analyze_transaction returns a list of input txids, can those txids be passed directly to analyze_transaction again, or must the LLM re-fetch? This breaks tool chaining.