Loading ToolBench
MCP server for HD wallet management, balance, and sync on EVM, UTXO, XRP via Crypto APIs
The server defines 15 tools with complete input schemas and basic descriptions, but falls short of production quality due to inconsistent parameter documentation, missing output schema documentation, and lack of error recovery guidance. Tools follow a clear naming convention (verb_noun with blockchain/network prefixes), but parameter descriptions are minimal (10-20 chars on average), far below the 72-char baseline for A+ tools. No tool includes guidance on when to use it vs. similar tools, nor do descriptions clarify state-modifying consequences. Output schemas are not documented in tool definitions, forcing LLMs to infer response structure. Error handling exists at the handler level but does not guide recovery or classify errors for agent decision-making.
Derive and sync a receiving address for an EVM HD wallet
Get details about an EVM HD wallet
List all addresses for an EVM HD wallet
List all assets held by an EVM HD wallet
List transactions for an EVM HD wallet
Prepare a transaction for an EVM HD wallet
Activate a wallet for synchronization
Delete a wallet
Parameter descriptions are minimal (10-20 characters), far below the 72-char baseline. Examples: 'The blockchain identifier' (27 chars), 'The network identifier' (22 chars). LLMs cannot infer valid values or constraints from these sparse descriptions. Descriptions must explain expected format, range, and allowed values.
Tool descriptions lack context for selection. None state WHEN to use this tool vs. similar tools (e.g., why call evm-derive-receiving-address instead of evm-derive-change-address?). None explain prerequisites or consequences. 'Derive and sync a receiving address' does not tell an LLM when this is the right choice.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Get the status of a wallet
List all wallets
Synchronize wallet data with blockchain
Derive and sync a change address for a UTXO-based HD wallet
Derive and sync a receiving address for a UTXO-based HD wallet
Get details about a UTXO-based HD wallet
List all addresses for a UTXO-based HD wallet
Output schemas are not documented in tool definitions. The handler code makes requests to CryptoAPIs endpoints (e.g., `/hd-wallets/evm/{blockchain}/{network}/{xpub}/details`), but no documentation specifies what fields the response contains. LLMs cannot plan chained calls without knowing output structure.
State-modifying tools (manage-delete-wallet, manage-activate-wallet, evm-prepare-transaction, etc.) do not declare this in descriptions. The risk field indicates DESTRUCTIVE and WRITE, but tool descriptions do not warn that these operations modify state or suggest confirmation patterns. Agents need to know which calls are idempotent.
Error handling exists in the handler (src/server.ts logs errors), but there is no guidance in tool descriptions or error responses about recovery steps. A failed derive call returns only the exception message, not 'Try activating the wallet first' or 'Check that the blockchain/network parameters are valid.'
'blockchain' and 'network' parameters lack enum constraints or explicit format documentation. The description 'The blockchain identifier' does not list valid values (e.g., 'eth', 'btc', 'xrp'?). LLMs cannot validate inputs without enums.
evm-prepare-transaction has a 'feePriority' enum (slow|standard|fast), which is good, but the 'data' parameter description is just 'Additional transaction data', not specifying format (hex string? JSON?), required length, or when it applies (smart contract calls only?).
utxo-list-addresses includes an 'addressFormat' parameter with enum values (p2pkh, p2sh, p2wpkh, p2pkh-cash, p2sh-cash), which is good, but this parameter is NOT marked as required in the schema. LLMs may omit it, leading to ambiguous results. If format is critical, either make it required or document the default behavior.
List tools (evm-list-addresses, evm-list-transactions, utxo-list-addresses, manage-list-wallets) accept 'limit' and 'offset' parameters but tool descriptions do not specify default values, acceptable ranges (e.g., limit 1-100), or whether total count is returned. Without this, LLMs cannot implement effective pagination.
No tool has a documented output schema. The rubric requires 100% of A+ tools to have documented return types. Currently, LLMs must infer what fields (address, balance, transactions, etc.) each API response contains, risking incorrect field references in downstream calls.