Loading ToolBench
MCP server for Hyperlane cross-chain messaging and asset transfer operations
The server defines 2 tools with moderate quality. Tool naming follows verb_noun pattern (cross-chain-*), which is correct. Descriptions exist but vary widely in detail. The cross-chain-asset-transfer has extensive, LLM-optimized documentation (nearly 600 chars with prerequisites, functionality breakdown, and examples), while cross-chain-message-transfer has a minimal description (27 chars). Input schemas are present and use Zod validation with regex patterns for Ethereum addresses, showing attention to validation. However, parameter descriptions lack strategic detail about when to use the tool, dependencies between parameters, and error recovery. No output schemas are documented, making it unclear what the agent receives. The tools handle financial/security-sensitive operations (asset transfers, message relay) but lack error categorization, confirmation patterns, or recovery guidance. Resource templates are implemented correctly with URI-based access to warp routes. Overall, the foundation is solid but lacks LLM-optimized descriptions, output documentation, and error handling patterns expected in production tools.
Transfers tokens/assets between multiple blockchain networks using Hyperlane's cross-chain infrastructure. FUNCTIONALITY: • Moves tokens from one blockchain to another (e.g., USDC from Ethereum to Polygon) • Supports sequential transfers across multiple chains in a single operation • Handles various token types including native tokens, ERC20 tokens, and synthetic tokens PREREQUISITES: • A warp route must exist for the specified token symbol and chain combination • If no warp route exists, deploy one first using the `deploy-warp-route` tool • Sufficient token balance on the origin chain • Sufficient gas tokens on all involved chains for transaction fees PARAMETERS: • symbol: The token identifier (e.g., "USDC", "ETH", "WBTC") • chains: Array of blockchain names in transfer order (e.g., ["ethereum", "polygon", "arbitrum"]) • amount: Token amount in wei or smallest token units (e.g., "1000000" for 1 USDC with 6 decimals) • recipient: Destination wallet address (defaults to sender if not specified) OUTPUT: • Returns transaction hashes and message IDs for each cross-chain transfer • Each transfer between adjacent chains generates one transaction • Use message IDs to track delivery status across chains EXAMPLE USE CASES: • Bridge USDC from Ethereum to Polygon • Multi-hop transfer: ETH from Ethereum → Arbitrum → Base • Cross-chain token arbitrage or yield farming
Transfers a cross-chain message.
Minimal description for cross-chain-message-transfer (27 chars) provides no context for LLM tool selection. Does not answer WHAT the tool does beyond a bare statement, WHEN to use it vs asset-transfer, or what it returns.
No output schemas documented for either tool. The LLM cannot plan downstream calls or extract necessary data (transaction hashes, message IDs, error states) from responses.
Missing error handling patterns. Financial/security-sensitive operations (asset transfers) lack confirmation steps, dry-run modes, or recovery guidance. An agent could inadvertently transfer large amounts without confirmation.
Parameter 'recipient' is optional for cross-chain-asset-transfer (defaults to sender) but this is not documented in the description. Undocumented defaults for financial operations risk unintended transfers.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No parameter dependency documentation. For cross-chain-asset-transfer, the 'chains' parameter must contain valid warp route combinations, but this prerequisite is buried in the description. Dependencies should be explicitly called out in parameter descriptions.
messageBody parameter in cross-chain-message-transfer lacks format constraints. Should specify byte limits, encoding (UTF-8?), and valid character sets to prevent LLM from passing oversized or invalid payloads.