Loading ToolBench
MCP server for broadcasting signed raw transactions to multiple blockchains via Crypto APIs
Server has 2 tools with mixed quality. broadcast_signed_transaction has a complete schema with enum constraints and detailed description including risk warnings; system_info is underspecified with no visible input schema or detailed description in the provided source. Tool names follow verb_noun convention (broadcast_*, system_*). The broadcast tool's description is exceptionally detailed (275+ chars) and includes critical danger warnings, exceeding baselines. However, parameter descriptions lack granularity (e.g., 'blockchain protocol' could specify supported chains more explicitly in param descriptions, not just the enum). Output schemas are not documented in the tool definitions. Error handling is delegated to the server wrapper without per-tool recovery guidance. Schema quality is uneven: broadcast has strong enums and required field clarity; system_info schema is not visible in source, capping its score.
Broadcast locally signed transaction (Broadcast product). Submit a signed transaction hex to the network. Supported blockchains and networks vary; see credits for per-chain cost. ⚠️ DANGEROUS ACTIONS: broadcast-signed-transaction — Broadcasting a signed transaction is irreversible. Once submitted to the network, it cannot be recalled or cancelled. Impact: The transaction will be submitted to the blockchain network and, if valid, will be included in a block permanently.
Get system information and API health status
system_info tool has no visible input schema or detailed description in source code. Tool imported from @cryptoapis-io/mcp-shared without inline definition. Cannot verify schema validity or parameter clarity.
Output schemas not documented for either tool. Callers (and LLMs) cannot infer the shape of responses, broadcast_signed_transaction returns 'unknown', system_info response structure is opaque. This violates the pattern that 100% of A+ tools have documented return types.
broadcast_signed_transaction includes confirmationToken as an optional parameter but provides no guidance on when/how to obtain it or what happens if it is omitted for dangerous actions. Documentation is incomplete on the confirmation workflow.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Error handling in server.ts is generic, catches errors, logs them with minimal context, and re-throws. Tool descriptions do not include recovery guidance (e.g., 'If broadcast fails with network error, retry or check chain status'). Errors do not classify as retryable vs. fatal.
Tool descriptions lack dependency hints. broadcast_signed_transaction does not state 'You must have a hex-encoded signed transaction' or 'Verify the blockchain/network pair is supported before calling.' No discovery guidance.