Hyperlane MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HOME | No | Home directory (fallback for CACHE_DIR) | |
| CACHE_DIR | No | Directory for storing local data | ~/.hyperlane-mcp |
| PRIVATE_KEY | Yes | Private key for signing transactions (without 0x prefix) | |
| GITHUB_TOKEN | Yes | GitHub Personal Access Token for accessing Hyperlane registry |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| cross-chain-message-transferC | Transfers a cross-chain message. |
| cross-chain-asset-transferA | 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 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 |
| deploy-warp-routeD | Deploys a warp route. |
| deploy-chainC | Deploys a new chain to the Hyperlane network. |
| run-validatorC | Runs a validator for a specific chain. |
| run-relayerC | Runs a relayer for specified chains. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Most tools have distinct purposes, such as cross-chain-asset-transfer for moving tokens and deploy-warp-route for creating routes. However, run-relayer and run-validator could be confused as both involve running infrastructure components, though their descriptions clarify they target different roles (relayer vs. validator).
All tool names follow a consistent kebab-case pattern with clear verb-noun structures, such as cross-chain-asset-transfer, deploy-warp-route, and run-relayer. This uniformity makes the set predictable and easy to navigate.
With 6 tools, the server is well-scoped for managing cross-chain operations, covering key actions like asset transfers, message transfers, chain deployment, route deployment, and running relayers/validators. Each tool earns its place without being overwhelming or insufficient.
The tool set covers core cross-chain workflows, including asset transfers, message transfers, and infrastructure setup. A minor gap exists in monitoring or querying tools, such as checking transfer status or listing existing routes, but agents can work around this using the provided outputs like message IDs.