Deploying core contracts and transferring assets both spend gas from the private key in the config, so this belongs on a key funded for the purpose and not on your main one. What it buys you is sequencing: deploy, bring up the validator and relayer, and send the first message as one continuous thread instead of a series of CLI invocations you have to get in the right order.
An MCP server over Hyperlane's cross-chain infrastructure. It keeps a local registry of chain metadata, deployed contracts and warp route configuration, deploys core contracts, and runs validators and relayers as Docker containers so each stays isolated.
- `deploy-chain` — deploy Hyperlane core contracts to a new chain
- `run-validator` and `run-relayer` — start the two pieces that make messages verifiable and deliverable, each in its own Docker container
- `cross-chain-message-transfer` — send a message from one chain to another
- `deploy-warp-route` and `cross-chain-asset-transfer` — stand up a route for asset transfers, then move tokens over it, including multi-hop
- Warp route configuration readable as a resource under the URI pattern `hyperlane-warp:///{symbol}/{/chain*}`
- Connections to several networks at once through Hyperlane's MultiProvider
A private key with enough native tokens to pay gas on every chain you touch, supplied as `PRIVATE_KEY` without the `0x` prefix, and a GitHub personal access token as `GITHUB_TOKEN` for registry access. Docker must be running, since validators and relayers are containers. Node.js v18 or higher and pnpm; clone the repository, `pnpm install`, `pnpm build`, and point the client at `build/index.js`. `CACHE_DIR` moves the local registry off its default of `~/.hyperlane-mcp`. You also need RPC endpoints for the chains involved.