Loading ToolBench
A MCP server for SperaxOS that supports Arbitrum One with USDs, SPA, Demeter, and other popular EVM-compatible networks.
Server has 21 tools across blocks, bridge, contracts, deployment, and domains. Most tools have descriptions and input schemas, but quality varies. Naming is generally clear and action-verb based. Descriptions are present but often terse (15-50 chars for many tools). Schemas are visible for all tools with proper JSON Schema structure, but several issues emerge: (1) Parameter descriptions vary in quality, some are clear, others minimal. (2) No output schemas documented, critical for tools like get_block_by_hash or read_contract that return complex data. (3) Error handling is not evident in the tool definitions. (4) High-risk operations (execute_bridge, write_contract, deploy_contract, deploy_create2) accept private keys as parameters, a CRITICAL SECURITY violation. (5) Some parameters like 'abi' in read_contract and write_contract lack format guidance. (6) No evidence of idempotency hints or retry guidance. Tools are individually well-named but collectively lack composition guidance.
Check if an ENS name is available for registration
Deploy a smart contract from bytecode and constructor arguments
Deploy a contract using CREATE2 for deterministic addresses across chains
Execute a cross-chain bridge transfer
Get a block by hash
Get a block by number
Get a range of blocks with summary information
CRITICAL: Private keys exposed as tool parameters. Tools execute_bridge, write_contract, deploy_contract, deploy_create2 accept privateKey as input. This is a fundamental security violation, private keys must never appear in tool parameters as they will be logged, traced, and persisted in agent histories.
No output schemas documented for any tool. The rubric requires documented return types for A+ tools. Tools like get_block_by_hash, read_contract, and get_block_with_transactions likely return complex nested objects (block data, transaction arrays, etc.) but the output structure is not specified in the tool definitions provided.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 53 | - | v1 |
Get all transaction receipts for a specific block
Get a block with full transaction details (not just hashes)
Get a quote for bridging tokens across chains
Track the status of a bridge transaction
Get the avatar URL for an ENS name
Get text records for an ENS name (avatar, twitter, email, etc.)
Get the latest block
List all supported bridge protocols and their capabilities
Get uncle (ommer) blocks for a specific block. Uncle blocks are valid blocks that weren't included in the main chain.
Check if an address is a smart contract or an externally owned account (EOA)
Read data from a smart contract by calling a view/pure function
Resolve an ENS name to its Ethereum address
Get the ENS name for an Ethereum address (reverse lookup)
Write data to a smart contract by calling a state-changing function
Descriptions too terse and lack WHEN/WHY guidance. Many descriptions are 50 - 60 characters with no context on when to use the tool vs alternatives. E.g., 'Get a block by hash' vs 'Retrieve a block from the blockchain by its 32-byte hash. Use this to look up a specific block when you know its hash; use get_block_by_number for height-based lookups.'
Parameter 'abi' in read_contract and write_contract has no format guidance. Description says 'The ABI of the smart contract function, as a JSON array' but does not explain the ABI schema format (is it the standard Solidity ABI JSON? What fields are required? Can it be a string or must it be an array object?). LLMs cannot construct valid ABIs from vague descriptions.
No error handling or recovery guidance. None of the tools specify what errors can occur, how to interpret them, or what the agent should do next. E.g., execute_bridge should document: 'Fails if token not supported on source chain; fails if insufficient balance; fails if private key invalid. In all cases, no funds are transferred.' This guides retry vs user-fixable decisions.
No idempotency hints or safe-to-retry guidance. Tools like get_block_by_hash are clearly idempotent (read-only), but this is not declared via toolAnnotations (readOnlyHint). Tools like deploy_contract are irreversible but have no idempotentHint=false or destructiveHint=true declaration.
Parameter 'blockNumber' and 'startBlock' described as strings but semantically integers. Descriptions should specify: 'Block number as a string (e.g., "12345") or hex string (e.g., "0x3039"). Will be converted to a BigInt for RPC calls.' Without this, LLMs may pass decimal strings, hex without 0x prefix, or other invalid formats.
Network parameter lacks enum constraint. Description says 'e.g., ethereum, bsc, polygon' but does not list all valid values or declare them as an enum. LLMs will hallucinate network names like 'eth', 'bnb', 'polygon-mainnet', etc., causing failures. All 21 tools accept 'network' but none constrain it formally.
No composition guidance for multi-step flows. E.g., if a user wants to 'call a contract and get the block it was included in', there's no documentation suggesting: search for tx → get_block_by_number with the tx's blockNumber. Or for bridges: get_bridge_quote → verify token approved → execute_bridge. LLMs spend extra reasoning cycles on trial-and-error instead of following documented patterns.
No rate limiting or result cap documentation. Tools like get_block_range could return thousands of blocks if endBlock is set far ahead of startBlock. No documented limit (e.g., max 1000 blocks per call) means agents could request gigabytes of data, exhausting context windows and costs.