Loading ToolBench
MCP Server generated from OpenAPI spec for bitcoin---merged-services-api
This server exposes 5 well-named Bitcoin blockchain query tools with comprehensive input schemas and clear descriptions. All tools follow verb_noun naming conventions (satoshi_*, brc20_*), have descriptions between 150 - 350 chars (within baseline), and define full input schemas with enum constraints and parameter descriptions. However, output schemas are completely undocumented, the tool definitions declare inputs but never specify what fields/types the caller receives. Parameter descriptions are present and detailed, but several critical gaps prevent this from reaching 80: no error handling guidance, no pagination documentation despite tools supporting cursor-based pagination, and no explicit output schema contracts. The generated-from-OpenAPI nature suggests schemas exist in the OpenAPI spec but are not exposed in the MCP tool definitions. Descriptions avoid example values and use enums for constrained inputs (activity_kind, order), which is excellent for LLM disambiguation. All 5 tools are read-only, reducing security risk.
Returns a collection of BRC20 tokens associated with the address, showing both the total and available (transferable) balances. This is essential for building BRC20 token wallets and dashboards.
Returns all unspent BRC20 transfer inscriptions residing at the address. This endpoint is critical for applications facilitating token transfers, as it identifies transfer-eligible inscriptions.
Returns the historical satoshi balances, itemized by block and including USD price.
Returns all transactions for a given address or script pubkey, allowing insight into when the balance increased, decreased, or remained the same. This endpoint supports customization to narrow results by time, transaction type, or ordering, enabling tailored historical views.
Returns the total balance in satoshis held at the specified address or script pubkey by summing all unspent outputs (UTXOs). This is a direct snapshot of the address's spendable funds and does not include mempool transactions.
Output schemas completely undocumented. Tools accept well-defined inputs but return type is unknown to the LLM caller. CallToolResult provides content but no schema is declared for what fields/types to expect from the API response.
No error handling guidance in tool descriptions. Tools do not explain how to handle common failure modes (invalid address, API timeouts, malformed script pubkey). LLM has no recovery path documented.
Pagination parameters present (cursor, count) but no explicit pagination documentation in tool descriptions. Tools support cursor-based pagination but do not document expected response format or how to detect end-of-results.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 77 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter 'address' accepts 'Bitcoin address or hex encoded script pubkey' but does not specify format constraints (length, character set, validation regex). LLM cannot validate input before calling.
No explicit per-tool result limits documented. Tools accept 'count' parameter with default 100 and minimum 0, but no maximum is stated. Unbounded counts could cause context window exhaustion.