Loading ToolBench
Bitcoin-native MCP server for AI agents: BTC/STX wallets, DeFi yield, sBTC peg, NFTs, and x402 payments.
The server registers 15 tools with varying quality. All tools have descriptions visible in the code, but parameter schemas are inconsistently documented. Tools like `arxiv_search`, `atstake_legion_status`, and `transfer_btc` have properly typed input parameters with descriptions, while others lack explicit schema validation. The descriptions range from detailed (arxiv tools, atstake tools) to adequate (bitcoin tools) to minimal (bitflow tools). Output schemas are not documented anywhere. Error handling guidance is largely absent. The tool names follow verb_noun convention consistently (e.g., get_btc_balance, transfer_btc), which is a strength. However, many parameter descriptions lack actionable format constraints, and no tools document their return structure. Critical gap: tool annotations (readOnlyHint, destructiveHint, idempotentHint) are declared in the metadata ('Risk: READ_ONLY' or 'Risk: IRREVERSIBLE') but NOT visible in the actual MCP tool registration code shown.
Compile a Markdown digest from recent arXiv papers (in-memory). Mirrors the arxiv-research skill functionality.
List recent digest files from ~/.aibtc/arxiv-research/digests/
Fetch recent papers from arXiv and score them for LLM/agent relevance. Queries the public arXiv Atom API (no API key required). Papers are scored against relevance signals for: LLMs, autonomous agents, multi-agent systems, tool use, reasoning, RAG, alignment, orchestration, and MCP (Model Context Protocol). Default categories: cs.AI, cs.CL, cs.LG, cs.MA (configurable). Category boosts: cs.MA +3, cs.CL +1, cs.AI +1. Returns total paper count, relevant paper count, and top papers by score. Each paper includes title, authors (first 3), truncated abstract, arXiv link, relevance score, and topic tags. Read-only. No API key required.
Every proposal in both legions, with tallies, rationales and the member roll, from the aggregated read the legions site itself renders.
Where a legion stands and whether you can act in it right now: your weight, the vault, the rules, and every gate between you and a proposal. Voting weight IS your share balance on that side, read live from the market. Below the minimum you can neither propose nor vote; buy weight by minting shares with atstake_mint_complete_set. Read-only. Defaults to the unlocked wallet, which requires one; pass an address to read anyone without unlocking.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) declared in metadata but NOT visible in MCP server registration code. The 'Risk:' labels in the specification are not translated to MCP tool annotations.
Output schemas not documented. Tools like arxiv_search, get_btc_balance, bitflow_get_quote return structured data but the response schema is not declared in tool definitions. LLMs cannot predict which fields to expect without seeing examples or schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | 1.27.1+ | v1 |
The El Salvador PoX-5 prediction market as it stands right now: the claim, whether it still trades, how much sBTC is escrowed, and how far the close height is. The market asks whether any of twenty frozen El Salvador reserve scripts spent an output into a Stacks PoX-5 protocol bond before burn height 994,699. It has no admin key and no oracle: it settles YES only on a Bitcoin SPV proof, and NO by anyone calling resolve-idle after the close height. Read-only, no wallet needed.
Share balances for an address, and what they are worth under each outcome. Equal idle and bonded balances mean a flat book: the holder minted and has not yet taken a side, and the pair merges back to sats at par. The directional position is the DIFFERENCE between the two. Read-only. Defaults to the unlocked wallet, which requires one; pass an address to read anyone without unlocking.
What the market is actually about: the twenty El Salvador reserve addresses, their output scripts, and the PoX-5 reward cycle indices that count. These are the addresses a YES proof must show spending into a lockup. Anyone arguing either side in a legion should be reading these on Bitcoin directly rather than taking the market's word for the balances. Read-only, no wallet needed.
Get a swap quote from Bitflow DEX with slippage protection.
Get market ticker data from Bitflow DEX. Returns price, volume, and liquidity information.
Execute a token swap on Bitflow DEX. Requires an unlocked wallet.
Get the BTC balance for a Bitcoin address. Returns both total balance (including unconfirmed) and confirmed balance.
Get current Bitcoin fee estimates for different confirmation targets. Returns fast (~10 min), medium (~30 min), and slow (~1 hour) fee rates in sat/vB.
List all UTXOs (Unspent Transaction Outputs) for a Bitcoin address. Useful for debugging, transparency, and understanding transaction inputs.
Transfer BTC to a recipient address. Builds, signs, and broadcasts a Bitcoin transaction. Requires an unlocked wallet with BTC balance. By default, only uses cardinal UTXOs (safe to spend - no inscriptions). Set includeOrdinals=true to allow spending ordinal UTXOs (advanced users only).
Bitflow tools have minimal descriptions (under 70 chars). bitflow_get_ticker: 'Get market ticker data from Bitflow DEX. Returns price, volume, and liquidity information.' does not explain WHEN to use it vs bitflow_get_quote, or what 'ticker data' includes. Violates pattern:tool-description (min 10 - 1024 chars, actionable context).
Parameter descriptions lack actionable constraints. Example: atstake_legion_status 'address' param has description 'Whose eligibility to report. Defaults to the unlocked wallet.' but does not state format (Stacks address starting with SP or SM), length, or what 'unlocked wallet' means to an agent unfamiliar with the domain.
Error handling and recovery guidance absent. No tool descriptions mention what to do if a call fails (e.g., 'If the address is invalid, check format or try search_addresses().'). Violates pattern:recovery-guide.
transfer_btc and bitflow_swap are irreversible operations but descriptions do not warn of or suggest a confirmation/dry-run pattern. LLMs could invoke these unintentionally. Violates pattern:confirmation-request.
Inconsistent parameter naming across tools. arxiv_search uses 'categories' (plural), but other tools use 'side' (atstake_*). Bitcoin address parameter is sometimes 'address', sometimes implicit. Violates pattern:tool (consistent naming for similar concepts).
No pagination guidance for list tools. arxiv_compile_digest accepts max_results (default 50, max 200), but it is unclear whether this caps the response or fetches more and truncates. No cursor, offset, or total_count documented. Violates pattern:paginated-result.