Manages Docker containers for running Hyperlane validators and relayers, handling container lifecycle and persistent storage for cross-chain infrastructure.
Enables deployment of Hyperlane core contracts, cross-chain messaging, and asset transfers on Ethereum and other EVM-compatible blockchains.
Accesses Hyperlane registry data stored on GitHub for chain metadata, contract configurations, and warp route information.
Supports cross-chain messaging and asset transfers between Polygon and other blockchain networks through Hyperlane protocol.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Hyperlane MCP Server deploy a warp route for USDC between Ethereum and Arbitrum"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A powerful Model Context Protocol (MCP) server that provides seamless integration with the Hyperlane protocol, enabling LLM assistants to interact with cross-chain messaging and smart contracts across multiple blockchains.
Related MCP server: HyperEVM MCP
The Hyperlane MCP Server bridges the gap between LLM assistants and the Hyperlane cross-chain infrastructure. It provides a standardized interface for deploying chains, managing validators and relayers, sending cross-chain messages, and deploying warp routes for asset transfers.
The server operates as an MCP (Model Context Protocol) server that:
Connects to Multiple Blockchains: Uses Hyperlane's MultiProvider to manage connections to various blockchain networks
Manages Local Registry: Maintains a local cache of chain metadata, deployed contracts, and warp route configurations
Deploys Infrastructure: Handles deployment of Hyperlane core contracts, validators, and relayers
Facilitates Cross-Chain Operations: Enables message passing and asset transfers between chains
Provides Docker Integration: Runs validators and relayers in Docker containers for isolation
LocalRegistry: Extends Hyperlane's registry system with local storage capabilities
HyperlaneDeployer: Handles deployment of core Hyperlane contracts
ValidatorRunner: Manages validator Docker containers
RelayerRunner: Manages relayer Docker containers
WarpRoute: Handles deployment and management of cross-chain asset routes
Send messages between different blockchain networks
Monitor message delivery status
Handle message verification and execution
Deploy Hyperlane core contracts to new chains
Deploy and configure warp routes for asset transfers
Manage contract configurations and upgrades
Run validators for message verification
Run relayers for message delivery
Monitor validator and relayer health
Handle Docker container lifecycle
Deploy warp routes for cross-chain asset transfers
Execute multi-hop asset transfers
Support various token types (native, synthetic, collateral, etc.)
Node.js: v18 or higher
Package Manager: pnpm (recommended)
Docker: For running validators and relayers
Operating System: Linux, macOS, or Windows with WSL2
Access to RPC endpoints for target blockchain networks
Stable internet connection for cross-chain operations
Sufficient bandwidth for Docker image downloads
Private key with sufficient native tokens for gas fees
Access to blockchain RPC endpoints
Understanding of target chain configurations
git clone https://github.com/yourusername/hyperlane-mcp.git
cd hyperlane-mcp# Install pnpm if not already installed
npm install -g pnpm
# Install project dependencies
pnpm installpnpm buildCreate a .env file in the project root:
cp .env.example .envEdit the .env file with your configuration:
# Required: Private key for signing transactions (without 0x prefix)
PRIVATE_KEY=your_private_key_here
# Required: GitHub Personal Access Token for registry access
GITHUB_TOKEN=your_github_personal_access_token
# Optional: Custom cache directory (defaults to ~/.hyperlane-mcp)
CACHE_DIR=/path/to/custom/cache/directory# Ensure Docker is running
docker --version
docker psVariable | Required | Description | Default |
| Yes | Private key for transaction signing (without 0x prefix) | None |
| Yes | GitHub PAT for accessing Hyperlane registry | None |
| No | Directory for storing local data |
|
| No | Home directory (fallback for CACHE_DIR) | System default |
For Claude Desktop or other MCP clients, add this configuration:
{
"mcpServers": {
"hyperlane": {
"command": "node",
"args": [
"/path/to/hyperlane-mcp/build/index.js"
],
"env": {
"PRIVATE_KEY": "your_private_key",
"GITHUB_TOKEN": "your_github_token"
"CACHE_DIR": "your_cache_dir"
}
}
}
}# Development mode
pnpm start
# Production mode
node build/index.js
# With MCP Inspector (for debugging)
pnpm inspectDeploy a New Chain: Use deploy-chain tool to add a new blockchain
Run Validator: Use run-validator to start message validation
Run Relayer: Use run-relayer to enable message delivery
Deploy Warp Route: Use deploy-warp-route for asset transfers
Send Messages/Assets: Use transfer tools for cross-chain operations
deploy-chain: Deploy Hyperlane core contracts to a new chain
run-validator: Start a validator for a specific chain
run-relayer: Start a relayer for cross-chain message delivery
cross-chain-message-transfer: Send messages between chains
cross-chain-asset-transfer: Transfer assets using warp routes
deploy-warp-route: Deploy new warp routes for asset transfers
Warp Route Configs: Access via hyperlane-warp:///{symbol}/{/chain*} URI
hyperlane-mcp/
├── src/ # Source code
│ ├── index.ts # Main MCP server entry point
│ ├── localRegistry.ts # Local registry implementation
│ ├── hyperlaneDeployer.ts # Core contract deployment
│ ├── RunValidator.ts # Validator Docker management
│ ├── RunRelayer.ts # Relayer Docker management
│ ├── warpRoute.ts # Warp route deployment
│ ├── msgTransfer.ts # Message transfer logic
│ ├── assetTransfer.ts # Asset transfer logic
│ ├── config.ts # Configuration utilities
│ ├── utils.ts # Utility functions
│ ├── types.ts # Type definitions
│ ├── logger.ts # Logging configuration
│ ├── gcr.ts # Google Container Registry utilities
│ ├── file.ts # File system utilities
│ ├── configOpts.ts # Configuration options
│ └── consts.ts # Constants
├── build/ # Compiled JavaScript output
├── node_modules/ # Dependencies
├── package.json # Project configuration
├── tsconfig.json # TypeScript configuration
├── .env # Environment variables (create this)
└── README.md # This fileThe server creates and manages several directories and files during operation:
~/.hyperlane-mcp/ # Main cache directory
├── chains/ # Chain configurations
│ ├── {chainName}.yaml # Chain metadata
│ ├── {chainName}.deploy.yaml # Deployed contract addresses
│ └── {chainName}-core-config.yaml # Core deployment config
├── routes/ # Warp route configurations
│ └── {symbol}-{hash}.yaml # Warp route configs
├── agents/ # Agent configurations
│ └── {chainName}-agent-config.json # Validator/relayer configs
└── logs/ # Runtime data and logs
├── hyperlane_db_validator_{chain}/ # Validator database
├── hyperlane_db_relayer/ # Relayer database
└── hyperlane-validator-signatures-{chain}/ # Validator signatures{chainName}.yaml: Contains chain metadata (RPC URLs, chain ID, native token info)
{chainName}.deploy.yaml: Deployed contract addresses (mailbox, ISM, hooks, etc.)
{chainName}-core-config.yaml: Core deployment configuration
{symbol}-{hash}.yaml: Warp route configuration for cross-chain asset transfers
{chainName}-agent-config.json: Configuration for validators and relayers
Validator databases: Persistent storage for validator state
Relayer databases: Persistent storage for relayer state
Signature storage: Validator checkpoint signatures
Docker containers: Validator and relayer containers (managed automatically)
Log files: Runtime logs from validators and relayers
Deploy Hyperlane core contracts to a new blockchain called "mytestnet" with chain ID 12345, RPC URL "https://rpc.mytestnet.com", native token symbol "MTN", and token name "MyTestNet Token". This should be marked as a testnet.Send a cross-chain message from Ethereum to Polygon. The recipient address should be 0x742d35Cc6634C0532925a3b8D4C9db96c4b4d8b6 and the message body should be "Hello from Ethereum!"Deploy a warp route for asset transfers between Ethereum and Arbitrum chains. Use collateral token type for Ethereum and synthetic token type for Arbitrum.Transfer assets using the USDC warp route from Ethereum to Arbitrum. Transfer 100 USDC to recipient address 0x742d35Cc6634C0532925a3b8D4C9db96c4b4d8b6. First, fetch the warp route configuration for USDC on these chains using the resources.Start a validator for the "mytestnet" chain that we deployed earlier.Start a relayer to handle message delivery between Ethereum and mytestnet chains. Use "mytestnet" as the validator chain name.Transfer 50 USDC from Ethereum to Polygon, then from Polygon to Arbitrum, using the existing USDC warp routes. The final recipient should be 0x742d35Cc6634C0532925a3b8D4C9db96c4b4d8b6.Show me the available warp route configurations for USDC token across Ethereum and Polygon chains.Deploy a new warp route for a custom token called "MyToken" (symbol: MTK) between three chains: Ethereum (collateral type), Polygon (synthetic type), and Arbitrum (synthetic type).# Add user to docker group (Linux)
sudo usermod -aG docker $USER
# Restart shell or logout/loginEnsure your wallet has sufficient native tokens for gas
Check current gas prices on target networks
Verify RPC URLs are accessible
Check for rate limiting on RPC providers
Consider using multiple RPC endpoints
# Check Docker logs
docker logs <container_id>
# Verify Docker image availability
docker pull gcr.io/abacus-labs-dev/hyperlane-agent:agents-v1.4.0Run with MCP Inspector for detailed debugging:
pnpm inspectCheck logs in the cache directory:
# Validator logs
tail -f ~/.hyperlane-mcp/logs/validator-{chain}.log
# Relayer logs
tail -f ~/.hyperlane-mcp/logs/relayer.logContributions are welcome! Please feel free to submit a Pull Request.
Fork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request
Use TypeScript for all new code
Follow existing code formatting (Prettier)
Add JSDoc comments for public APIs
Include error handling
This project is licensed under the MIT License.
The software is provided as is. No guarantee, representation or warranty is being made, express or implied, as to the safety or correctness of the software. It has not been audited and as such there can be no assurance it will work as intended. Users may experience delays, failures, errors, omissions, loss of transmitted information or loss of funds. The creators are not liable for any of the foregoing. Users should proceed with caution and use at their own risk.
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
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Token symbol to transfer | |
| chains | Yes | Chains to transfer asset between in order of transfer | |
| amount | Yes | Amount to transfer (in wei or token units) | |
| recipient | No | Recipient address | 0x1Be31A94361a391bBaFB2a4CCd704F57dc04d4bb |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it's a write operation (implied by 'transfers'), requires specific prerequisites (warp routes, balances), involves multiple transactions (one per chain hop), and provides tracking capabilities (message IDs). However, it doesn't mention rate limits, error handling, or confirmation times, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (FUNCTIONALITY, PREREQUISITES, etc.) and uses bullet points for readability. While comprehensive, some sections like EXAMPLE USE CASES could be more concise. Overall, it's appropriately sized and front-loaded with core functionality, though minor trimming could improve efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of cross-chain transfers, no annotations, and no output schema, the description does a strong job covering prerequisites, parameters, behavior, and examples. It explains the multi-step nature and output structure. However, it lacks details on error cases, timeouts, or specific chain naming conventions, which could be important for robust usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema: it explains parameter purposes with examples (e.g., 'USDC from Ethereum to Polygon'), clarifies units ('wei or smallest token units'), and specifies default behavior for recipient. This provides practical guidance that enhances understanding beyond the schema's technical definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('transfers tokens/assets between multiple blockchain networks') and resources ('using Hyperlane's cross-chain infrastructure'). It distinguishes from siblings by focusing on asset transfers rather than message transfers, chain deployment, or route deployment, making the differentiation explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs alternatives, including prerequisites like requiring a warp route (with a specific alternative tool named: 'deploy-warp-route') and conditions like sufficient balances. It also outlines use cases and distinguishes from siblings by focusing on asset transfers rather than other cross-chain operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transfers a cross-chain message.
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | Origin chain | |
| destination | Yes | Destination chain | |
| recipient | Yes | Recipient address | |
| messageBody | Yes | Message body |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. 'Transfers' implies a write/mutation operation, but there's no mention of permissions required, whether this is an asynchronous operation, what happens on failure, rate limits, or any other behavioral characteristics. The description doesn't contradict annotations (none exist), but fails to provide necessary context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise with a single sentence containing only four words. While this represents under-specification rather than ideal conciseness, it contains zero wasted words and is perfectly front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a cross-chain operation tool with 4 parameters, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what a 'cross-chain message' entails, what happens after transfer, error conditions, or any operational context. The combination of minimal description with missing structured metadata creates significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents all four parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify edge cases. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Transfers a cross-chain message' is a tautology that essentially restates the tool name 'cross-chain-message-transfer' without adding meaningful specificity. It doesn't distinguish this tool from its sibling 'cross-chain-asset-transfer' or explain what constitutes a 'message' versus an 'asset' in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'cross-chain-asset-transfer', 'deploy-chain', 'deploy-warp-route', 'run-relayer', and 'run-validator', there's no indication of when message transfer is appropriate versus asset transfer or other cross-chain operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploys a new chain to the Hyperlane network.
| Name | Required | Description | Default |
|---|---|---|---|
| chainName | Yes | Name of the chain to deploy | |
| chainId | Yes | Chain ID of the chain to deploy | |
| rpcUrl | Yes | RPC URL for the chain | |
| tokenSymbol | Yes | Native token symbol | |
| tokenName | Yes | Native token name | |
| isTestnet | No | Whether this is a testnet chain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Deploys' which implies a write/mutation operation, but doesn't cover critical aspects like permissions needed, whether it's destructive, rate limits, or what happens on failure. This is a significant gap for a deployment tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deployment tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'deploying a chain' entails operationally, what the expected outcome is, or any behavioral constraints. Given the complexity implied by 6 parameters, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deploys') and resource ('a new chain to the Hyperlane network'), providing a specific purpose. However, it doesn't explicitly differentiate from sibling tools like 'deploy-warp-route' or 'run-relayer', which may involve different deployment aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based on the name alone without distinguishing from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploys a warp route.
| Name | Required | Description | Default |
|---|---|---|---|
| warpChains | Yes | Warp chains to deploy the route on | |
| tokenTypes | Yes | Token types to deploy |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails completely. It doesn't indicate whether this is a read or write operation, what permissions might be required, whether it's destructive or reversible, what side effects might occur, or any rate limits or constraints. The single sentence offers zero behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three words, this represents under-specification rather than effective brevity. The description is too sparse to be helpful, failing to provide the necessary context that would earn its place in a tool definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deployment tool with no annotations and no output schema, the description is completely inadequate. It doesn't explain what a warp route is, what deployment entails, what happens after deployment, or any behavioral characteristics. Given the complexity implied by the parameter arrays and token type enums, this minimal description leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents both parameters ('warpChains' and 'tokenTypes') adequately. The description adds no additional meaning about these parameters beyond what the schema provides, so it meets the baseline expectation without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Deploys a warp route' is a tautology that essentially restates the tool name, providing no additional specificity about what a warp route is or what deployment entails. It lacks a clear verb+resource combination and doesn't distinguish this tool from sibling tools like 'deploy-chain' or 'cross-chain-asset-transfer' in any meaningful way.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. There's no mention of prerequisites, appropriate contexts, or comparisons to sibling tools like 'deploy-chain' or 'cross-chain-asset-transfer' that might handle related functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs a relayer for specified chains.
| Name | Required | Description | Default |
|---|---|---|---|
| relayChains | Yes | Chains to relay between | |
| validatorChainName | Yes | Name of the validator chain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'runs a relayer' but doesn't explain what this operation does (e.g., starts a process, configures a service, performs a one-time action), its effects (e.g., ongoing relay, resource consumption), or any constraints (e.g., permissions, dependencies). This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for the tool's complexity and front-loads the core action, though it lacks detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a 'run' operation with no annotations or output schema), the description is incomplete. It doesn't explain what 'runs' means behaviorally, what a relayer is, or what the expected outcome is, leaving significant gaps for the agent to understand the tool's function and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema ('Chains to relay between', 'Name of the validator chain'). The description adds no additional meaning beyond this, such as format examples or relationships between parameters, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Runs a relayer for specified chains' states a verb ('runs') and resource ('relayer'), but is vague about what 'runs' entails (e.g., starts, executes, manages) and what a 'relayer' does in this context. It doesn't distinguish from siblings like 'run-validator' or 'cross-chain-asset-transfer', leaving the specific purpose unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or relationships to sibling tools like 'run-validator' or 'deploy-chain', leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs a validator for a specific chain.
| Name | Required | Description | Default |
|---|---|---|---|
| chainName | Yes | Name of the chain to validate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but discloses minimal behavioral traits. It implies an execution action ('runs') but doesn't specify if it's read-only, destructive, requires permissions, has side effects, or involves rate limits. This is inadequate for a tool that likely performs validation operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'validator' (likely a critical operation), no annotations, no output schema, and minimal description, this is incomplete. The description lacks details on what validation entails, expected outcomes, or error handling, making it insufficient for informed tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond the input schema, which has 100% coverage and fully documents the single parameter 'chainName'. Since schema coverage is high, the baseline is 3, and the description doesn't compensate with additional context like chain format or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Runs a validator for a specific chain' clearly states the action (runs) and target (validator for a chain), but it's vague about what 'runs' entails (e.g., starts, executes, validates) and doesn't distinguish from siblings like 'run-relayer' or 'deploy-chain'. It avoids tautology by not restating the name, but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., after deployment), or exclusions, leaving the agent to infer usage from the name alone among siblings like 'run-relayer' or 'deploy-chain'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
cross-chain-asset-transfercross-chain-message-transferdeploy-chaindeploy-warp-routerun-relayerrun-validatorMost 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage your blockchain infrastructure across 80+ chains with your agents.
Provides cloud browser automation capabilities using Stagehand and Browserbase, enabling LLMs to i…
Token swaps and honeypot/rug checks for AI agents on 8 chains, paid per-call in USDC via x402.
Cross-chain token swaps for autonomous agents on Base L2 and partner rails
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Suryansh-23/hyperlane-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
