The Relay MCP Server enables AI agents to interact with the Relay Protocol for cross-chain token bridging and swapping. All tools are read-only — they return quotes, fees, steps, and status, but do not sign or broadcast transactions directly (execution requires wallet integration).
Discover Supported Networks — List blockchain networks supported by Relay, filterable by VM type (EVM, SVM), to resolve chain names to IDs.
Find Supported Tokens — Search for tokens across chains by name or symbol, with filtering by chain IDs and verified status.
Get Bridge Quotes — Obtain quotes for bridging the same token between chains (e.g., ETH on Ethereum → ETH on Base), including fees and time estimates.
Get Swap Quotes — Obtain quotes for swapping different tokens, optionally across chains (e.g., ETH on Ethereum → USDC on Base).
Estimate Fees — Get a detailed fee breakdown (gas, relayer fees, total cost) for a bridge or swap without committing to execution.
Execute Bridges/Swaps — Retrieve unsigned transaction steps (approvals + deposits) needed to complete a bridge or swap, for both ERC-20 and native token flows.
Wallet Integration via WalletConnect — Pair a user's wallet (MetaMask, Rainbow, etc.) via QR code, check connection status, execute multi-step transaction flows, and disconnect. Private keys never leave the user's device.
Check Transaction Status — Poll the status of an in-progress or completed transaction using a request ID (waiting, pending, success, failure, refund).
View Transaction History — Retrieve past bridge and swap transactions for a wallet address, with pagination support.
Generate Deep Links — Create pre-filled URLs to the Relay web app so users can initiate transactions directly in their browser.
Provides tools for cross-chain bridging and swapping assets on Ethereum, including chain and token support discovery, fee estimation, and transaction data generation for AI agents.
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., "@Relay MCP Server Bridge 0.1 ETH from Ethereum to Base"
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 Model Context Protocol server for Relay Protocol — cross-chain bridge and swap tools for AI agents.
Tool | Description |
| Quote for bridging same token across chains |
| Quote for swapping between different tokens (same-chain or cross-chain) |
| Fee breakdown for a bridge or swap route |
Tool | Description |
| List supported blockchain networks (slim response) |
| Search for tokens across chains |
| Currently trending tokens across Relay-supported chains |
| Current USD price of a token |
| Full token fundamentals: price, market cap, volume, liquidity, optional price chart |
| List DEX aggregators and AMMs that Relay routes through |
Tool | Description |
| Chain health, solver liquidity, and route configuration (3 API calls in 1 tool) |
Tool | Description |
| Check status by request ID or on-chain tx hash |
| Past transactions for a wallet |
| Tell Relay to index a transaction it may have missed |
Tool | Description |
| Claimable app fee balances and claim history (2 API calls in 1 tool) |
| Deep link to the Relay web app with pre-filled parameters |
| Discover Relay API endpoints and inspect their schemas |
Related MCP server: Hyperlane MCP Server
Add to your claude_desktop_config.json or .claude.json:
{
"mcpServers": {
"relay": {
"command": "npx",
"args": ["-y", "@relayprotocol/relay-mcp"]
}
}
}Add to .cursor/mcp.json:
{
"mcpServers": {
"relay": {
"command": "npx",
"args": ["-y", "@relayprotocol/relay-mcp"]
}
}
}npm install
npm run build
npm startVariable | Default | Description |
|
| Relay API base URL |
| — | Optional API key for higher rate limits |
Chain name resolution — Pass "base", "ethereum", "arb" instead of numeric chain IDs. Supports aliases and fuzzy matching.
Input validation — Addresses, amounts, and chain IDs are validated before hitting the API, with clear error messages.
Bundled tools — check_chain_status and get_app_fees combine multiple API calls into single tools with parallel fetching.
Decision-tree descriptions — Tool descriptions guide agents to pick the right tool ("For just the price, use get_token_price. For full fundamentals, use get_token_details.").
Slim responses — Responses are trimmed to essential fields. Chart data is downsampled from ~21KB to ~3KB.
API schema discovery — get_api_schema lets agents explore available endpoints on demand (progressive disclosure pattern).
Tx hash lookup — get_transaction_status accepts either a request ID or an on-chain transaction hash.
Structured errors — Errors are categorized (validation, api, network, rate_limit, server, auth) with retryability hints.
Transport: Stdio (MCP spec)
Runtime: Node.js >=20
API: Direct HTTP calls to api.relay.link (no SDK dependency)
Read-only: Returns quotes, fees, and status. Does not sign or broadcast transactions.
User: "Bridge 0.1 ETH from Ethereum to Base"
1. Agent calls get_bridge_quote(originChainId="ethereum", destinationChainId="base", ...)
→ chain names resolved automatically, quote returned with fees and ETA
2. Agent shows user the quote and a link to execute on relay.linkUser: "What tokens are trending on Base?"
1. Agent calls get_trending_tokens(chainId="base")
→ returns token identities (no prices)
2. Agent calls get_token_price for each interesting token
→ returns current USD pricesMIT
Estimate the fees for a bridge or swap without committing to execution. Returns a breakdown of gas fees, relayer fees, and total cost impact. Useful for comparing routes or showing users expected costs.
| Name | Required | Description | Default |
|---|---|---|---|
| originChainId | Yes | Source chain ID. | |
| destinationChainId | Yes | Destination chain ID. | |
| originCurrency | Yes | Origin token address. "0x0000000000000000000000000000000000000000" for native. | |
| destinationCurrency | Yes | Destination token address. "0x0000000000000000000000000000000000000000" for native. | |
| amount | Yes | Amount in the origin token's smallest unit. | |
| sender | Yes | Sender wallet address. |
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 does well by stating this is a non-committal estimation tool (not execution) and describing the return format breakdown. However, it lacks details about potential limitations, error conditions, rate limits, or authentication requirements that would be important for a fee estimation 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 perfectly concise with three sentences that each earn their place: first states the core purpose, second describes the return format, third provides usage context. No wasted words, well-structured and front-loaded with the most important information.
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 fee estimation tool with 6 parameters, 100% schema coverage, and no output schema, the description provides good contextual completeness. It explains the non-execution nature, return format breakdown, and usage scenarios. The main gap is the lack of output schema, but the description compensates by describing the return format ('breakdown of gas fees, relayer fees, and total cost impact').
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 already documents all 6 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, but it does provide context about what the tool does with those parameters (estimating fees for bridges/swaps). This 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 clearly states the tool's purpose with specific verbs ('estimate fees for a bridge or swap') and distinguishes it from execution tools like 'execute_bridge' by emphasizing 'without committing to execution'. It explicitly identifies the resource (fees) and scope (bridge/swap operations).
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 clear context for when to use this tool ('useful for comparing routes or showing users expected costs'), which implicitly differentiates it from execution tools. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools like 'get_bridge_quote' or 'get_swap_quote'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a quote and unsigned transactions for a bridge or swap via Relay. Returns ALL steps required to complete the transfer.
For ERC-20 tokens (like USDC), there are typically TWO steps:
approve — An ERC-20 approval transaction allowing Relay to spend the token.
deposit — The actual bridge/swap transaction.
For native tokens (ETH), there is usually just ONE step:
deposit — The bridge/swap transaction.
Some routes may also include a "signature" step (EIP-712 signing instead of a transaction).
Each step has a "kind" field:
"transaction" → must be signed and broadcast via eth_sendTransaction
"signature" → must be signed via eth_signTypedData_v4, then POSTed to the Relay API
After calling this tool, pass ALL the returned steps to the wallet tool with action "execute" to sign and submit them in order. The wallet tool handles the full multi-step flow automatically.
If a wallet is connected via the wallet tool, the sender defaults to the connected address. Returns a requestId for tracking status via get_transaction_status.
| Name | Required | Description | Default |
|---|---|---|---|
| originChainId | Yes | Source chain ID. | |
| destinationChainId | Yes | Destination chain ID. | |
| originCurrency | Yes | Origin token address. "0x0000000000000000000000000000000000000000" for native. | |
| destinationCurrency | Yes | Destination token address. "0x0000000000000000000000000000000000000000" for native. | |
| amount | Yes | Amount in the origin token's smallest unit (wei). | |
| sender | No | Sender wallet address. If omitted and a wallet is connected via the wallet tool, the connected address is used. | |
| recipient | No | Recipient wallet address. Defaults to sender. |
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 behaviors: it returns steps (not executes them), outlines the multi-step flow (approve/deposit for ERC-20, deposit for native), explains step kinds ('transaction' vs 'signature'), specifies how to handle returned steps (via wallet tool), mentions default sender behavior if wallet connected, and notes it returns a requestId for tracking. It doesn't cover error cases or rate limits, but provides substantial operational 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 well-structured and front-loaded with the core purpose. It uses bullet points and clear sections to explain steps and kinds, avoiding unnecessary repetition. While somewhat lengthy due to detailed explanations, every sentence earns its place by providing essential operational guidance. A slight deduction for density, but overall efficient.
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 tool's complexity (multi-step bridge/swap flow) and lack of annotations or output schema, the description does a strong job of providing context. It explains what the tool returns (steps, requestId), how to use the output (via wallet tool), and covers key behavioral aspects. It could briefly mention error handling or response format, but for a tool with no output schema, it's largely complete.
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 already documents all 7 parameters thoroughly. The description adds minimal parameter-specific information beyond the schema—it only implicitly relates to 'sender' by mentioning wallet connection defaults. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.
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: 'Get a quote and unsigned transactions for a bridge or swap via Relay. Returns ALL steps required to complete the transfer.' It specifies the verb ('Get'), resource ('quote and unsigned transactions'), and distinguishes from siblings like get_bridge_quote (which likely only returns a quote) and get_swap_quote by emphasizing it returns the full transaction steps needed for execution.
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: for obtaining the steps to execute a bridge/swap via Relay. It distinguishes from alternatives by noting that after calling this tool, you must pass the steps to the 'wallet' tool with action 'execute' for actual execution. It also clarifies the relationship with sibling tools like get_transaction_status for tracking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a quote for bridging the same token from one chain to another (e.g. ETH on Ethereum → ETH on Base). Returns estimated output amount, fees breakdown, and time estimate. Use get_swap_quote instead if you want to change the token type.
| Name | Required | Description | Default |
|---|---|---|---|
| originChainId | Yes | Source chain ID (e.g. 1 for Ethereum). | |
| destinationChainId | Yes | Destination chain ID (e.g. 8453 for Base). | |
| currency | Yes | Token address to bridge. Use "0x0000000000000000000000000000000000000000" for native ETH. | |
| amount | Yes | Amount to bridge in the token's smallest unit (wei for ETH). Example: "1000000000000000000" for 1 ETH. | |
| sender | Yes | Sender wallet address. | |
| recipient | No | Recipient wallet address. Defaults to sender if not provided. |
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 what the tool does (returns estimates and breakdowns) and clarifies it's for quoting only (not execution), which is useful context. However, it doesn't mention potential limitations like rate limits, error conditions, or whether the quote is time-sensitive, leaving some behavioral aspects uncovered.
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 perfectly concise and well-structured in just two sentences. The first sentence clearly states the purpose, scope, and return values, while the second provides crucial usage guidance. Every word earns its place with no redundancy or fluff.
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 tool's moderate complexity (6 parameters, no output schema, no annotations), the description provides excellent contextual completeness. It clearly explains what the tool does, when to use it, and what it returns. The only minor gap is the lack of output schema, but the description adequately describes the return values (estimated output amount, fees breakdown, time estimate).
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 input schema has 100% description coverage, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, but it does provide context about the tool's purpose that helps understand parameter usage. This meets the baseline of 3 when schema coverage is high.
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 ('Get a quote for bridging') and resources ('the same token from one chain to another'), and distinguishes it from sibling tools by explicitly mentioning when to use get_swap_quote instead. It provides concrete examples (ETH on Ethereum → ETH on Base) and specifies the return values (estimated output amount, fees breakdown, time estimate).
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 explicitly provides usage guidelines by stating 'Use get_swap_quote instead if you want to change the token type,' which clearly differentiates when to use this tool versus an alternative. This gives the agent specific direction on tool selection based on the user's intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a deep link to the Relay web app with pre-filled bridge/swap parameters. The user can open this URL in their browser to START a new transaction via the Relay UI. This is NOT a transaction tracking URL — do NOT use it to check on an in-progress transaction. For tracking, use get_transaction_status with the requestId.
| Name | Required | Description | Default |
|---|---|---|---|
| destinationChainId | Yes | Destination chain ID (e.g. 8453 for Base). This determines the Relay app page. | |
| fromChainId | No | Origin chain ID (e.g. 1 for Ethereum). If omitted, user picks in the UI. | |
| fromCurrency | No | Origin token address. "0x0000000000000000000000000000000000000000" for native. | |
| toCurrency | No | Destination token address. "0x0000000000000000000000000000000000000000" for native. | |
| amount | No | Pre-filled input amount in human-readable units (e.g. "0.1" for 0.1 ETH). | |
| toAddress | No | Recipient wallet address. | |
| tradeType | No | Trade type. Defaults to EXACT_INPUT. |
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 explains that this tool generates a URL for users to open in their browser to initiate transactions via the UI, which is valuable context beyond what the schema provides. However, it doesn't mention potential rate limits, authentication requirements, or error conditions.
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 perfectly concise and front-loaded. The first sentence states the core purpose, the second explains the user action, and the third provides critical usage guidance with a clear alternative. Every sentence earns its place with no wasted words.
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 tool with 7 parameters, no annotations, and no output schema, the description does well by clearly explaining the tool's purpose, usage context, and behavioral characteristics. However, it doesn't describe what the generated URL looks like or provide examples of the output format, which would be helpful given the lack of output schema.
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 already documents all 7 parameters thoroughly. The description doesn't add any additional parameter semantics beyond what's in the schema, but it does provide context about how the parameters are used ('pre-filled bridge/swap parameters'). This meets the baseline expectation when schema coverage is high.
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: 'Generate a deep link to the Relay web app with pre-filled bridge/swap parameters.' It specifies the exact action (generate a deep link) and resource (Relay web app), and distinguishes it from sibling tools by explicitly contrasting it with get_transaction_status for tracking purposes.
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 ('to START a new transaction via the Relay UI') and when not to use it ('do NOT use it to check on an in-progress transaction'). It also names a specific alternative tool for tracking purposes: 'For tracking, use get_transaction_status with the requestId.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all blockchain networks supported by Relay for bridging and swapping. Returns chain IDs, names, native currencies, and status. Use this to resolve chain names to chain IDs before calling other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| vmType | No | Filter by virtual machine type (e.g. "evm", "svm"). Omit for all chains. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format ('Returns chain IDs, names, native currencies, and status') and the tool's purpose in the broader workflow. However, it doesn't mention potential rate limits, authentication needs, or pagination behavior.
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?
Two sentences with zero waste: the first states purpose and return values, the second provides explicit usage guidance. Every word earns its place, and key information is front-loaded.
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 simple read-only tool with no annotations and no output schema, the description provides adequate context about what it does and when to use it. However, without an output schema, it could benefit from more detail about the return structure beyond the listed fields.
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 already documents the single optional parameter. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score 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 clearly states the specific action ('List all blockchain networks'), the resource ('supported by Relay'), and the purpose ('for bridging and swapping'). It distinguishes from siblings by focusing on chain metadata rather than transactions, fees, or tokens.
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?
Explicitly states when to use this tool: 'Use this to resolve chain names to chain IDs before calling other tools.' This provides clear guidance on its role in the workflow and distinguishes it from alternatives like get_supported_tokens or transaction-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for tokens supported by Relay across chains. Use this to find token contract addresses before getting quotes. Returns token symbol, name, address, and chain availability.
| Name | Required | Description | Default |
|---|---|---|---|
| chainIds | No | Filter to specific chain IDs (e.g. [1, 8453] for Ethereum and Base). Omit for all chains. | |
| term | No | Search by token name or symbol (e.g. "USDC", "ethereum"). | |
| verified | No | Only return verified tokens. Defaults to true. | |
| limit | No | Max number of token groups to return. Defaults to 20. |
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 describes the search functionality and return format (token symbol, name, address, chain availability), but lacks details on rate limits, authentication needs, error conditions, or pagination behavior beyond the 'limit' parameter. This is adequate but leaves gaps for a search 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 front-loaded with the core purpose in the first sentence, followed by usage guidance and return details. Every sentence earns its place with no wasted words, making it highly efficient and easy to scan.
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 tool's moderate complexity (search with filtering), no annotations, and no output schema, the description is reasonably complete. It covers purpose, usage context, and return format, but could benefit from more behavioral details (e.g., performance expectations or error handling) to fully compensate for the lack of structured fields.
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 four parameters. The description adds no additional parameter semantics beyond what's in the schema, but the baseline is 3 when schema coverage is high. The description does imply the tool's purpose aligns with the parameters (e.g., searching with 'term'), but doesn't enhance the schema's details.
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 ('Search for tokens supported by Relay across chains') and resources ('tokens'), distinguishing it from siblings like get_supported_chains (which focuses on chains rather than tokens) and get_swap_quote (which is for quotes, not token discovery).
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 clear context for when to use this tool ('Use this to find token contract addresses before getting quotes'), which implicitly suggests it's a preparatory step for tools like get_swap_quote or execute_bridge. However, it doesn't explicitly state when not to use it or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a quote for swapping between different tokens, optionally across chains (e.g. ETH on Ethereum → USDC on Base, or USDC → WETH on the same chain). Returns estimated output amount, fees, and time estimate.
| Name | Required | Description | Default |
|---|---|---|---|
| originChainId | Yes | Source chain ID (e.g. 1 for Ethereum). | |
| destinationChainId | Yes | Destination chain ID. Can be the same as originChainId for same-chain swaps. | |
| originCurrency | Yes | Token address to swap from. Use "0x0000000000000000000000000000000000000000" for native ETH. | |
| destinationCurrency | Yes | Token address to swap to. Use "0x0000000000000000000000000000000000000000" for native ETH. | |
| amount | Yes | Amount to swap in the origin token's smallest unit (wei for ETH). | |
| sender | Yes | Sender wallet address. | |
| recipient | No | Recipient wallet address. Defaults to sender. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's a read-only operation (returns a quote, not executes), outputs estimated amounts/fees/time, and supports cross-chain swaps. However, it lacks details on rate limits, error conditions, or authentication needs, which are important for a financial 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 efficiently structured in two sentences: the first states the purpose and scope with helpful examples, and the second specifies the return values. Every sentence adds critical information with zero waste, making it easy to parse.
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 (cross-chain swaps, 7 parameters) and no annotations/output schema, the description is reasonably complete: it covers purpose, scope, and return values. However, it could improve by mentioning prerequisites (e.g., wallet connectivity) or error handling, which would be valuable 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?
Schema description coverage is 100%, so the schema fully documents all 7 parameters. The description adds minimal value beyond the schema—it mentions 'optionally across chains' which aligns with destinationChainId, but doesn't explain parameter interactions or provide additional semantics. Baseline 3 is appropriate when 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 specific action ('Get a quote for swapping'), identifies the resources involved ('different tokens'), and distinguishes it from siblings like 'execute_bridge' (which performs the actual swap) and 'get_bridge_quote' (which is for bridging, not swapping). The examples ('ETH on Ethereum → USDC on Base') provide concrete differentiation.
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 clear context for when to use this tool ('for swapping between different tokens, optionally across chains') and implies alternatives through sibling tool names like 'execute_bridge' (for execution) and 'get_bridge_quote' (for bridging quotes). However, it does not explicitly state when NOT to use it or directly compare to these alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get past Relay bridge and swap transactions for a wallet address. Returns transaction IDs, statuses, chains, and timestamps. Supports pagination via cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | Wallet address to look up. | |
| limit | No | Max number of transactions to return. Defaults to 10. | |
| cursor | No | Pagination cursor from a previous response. Omit for the first page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: it returns specific data fields (transaction IDs, statuses, chains, timestamps) and supports pagination via cursor. However, it doesn't mention rate limits, authentication requirements, error conditions, or whether this is a read-only operation (though 'Get' implies reading). The description adds value but doesn't fully compensate for the lack of annotations.
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 two sentences with zero waste: the first sentence states the purpose and return data, the second adds pagination support. It's front-loaded with the core functionality and efficiently structured without unnecessary details.
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 no annotations and no output schema, the description provides basic completeness for a read operation: it states what data is returned and mentions pagination. However, for a tool with 3 parameters and no structured output definition, it could benefit from more detail on response format, error handling, or limitations. It's adequate but has clear gaps in behavioral context.
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 already documents all three parameters thoroughly. The description adds minimal value beyond the schema: it mentions pagination via cursor, which is already covered in the cursor parameter description. No additional parameter semantics are provided, so the baseline score 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 clearly states the verb ('Get') and resource ('past Relay bridge and swap transactions for a wallet address'), specifying the scope of transactions (bridge and swap) and the target (wallet address). It distinguishes from siblings like get_transaction_status (which checks individual transactions) and get_bridge_quote/get_swap_quote (which provide estimates rather than history).
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 implies usage for retrieving historical transaction data for a wallet, but doesn't explicitly state when to use this tool versus alternatives like get_transaction_status (for single transaction details) or other query tools. It mentions pagination support, which provides some context for handling large result sets, but lacks explicit guidance on use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a Relay bridge or swap transaction. Use the requestId returned from execute_bridge.
Statuses: waiting — The origin chain transaction has been broadcast but not yet confirmed on-chain. Just wait — no further action needed. pending — The relay network has picked up the request and is processing the cross-chain transfer. success — Complete. Funds have arrived on the destination chain. failure — The transaction failed. refund — The transaction was refunded to the sender.
IMPORTANT: After the wallet "execute" action completes all steps (approval + deposit), Relay handles the cross-chain delivery automatically. Poll every 5-10 seconds until success or failure. The user does NOT need to do anything else after execution completes — just wait.
| Name | Required | Description | Default |
|---|---|---|---|
| requestId | Yes | The request ID returned from execute_bridge or from a quote's steps[].requestId. |
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 the tool's behavior: it's a read-only status check (implied by 'Check'), discloses the possible status outcomes with explanations (waiting, pending, success, failure, refund), and provides operational context (Relay handles cross-chain delivery automatically, polling frequency). It doesn't mention rate limits or authentication needs, but covers the core behavioral aspects well.
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 and appropriately sized. It front-loads the core purpose, then provides status details, and concludes with important usage notes. While slightly longer than minimal, every sentence adds value (status explanations, workflow context, polling advice). No redundant or wasted content.
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 tool's moderate complexity (status checking with specific outcomes), no annotations, and no output schema, the description provides strong contextual completeness. It explains the status meanings, workflow integration, and polling behavior. The main gap is lack of explicit return format details, but the status explanations partially compensate for no output schema.
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 input schema has 100% description coverage, so the baseline is 3. The description adds significant value beyond the schema by explaining the parameter's origin ('requestId returned from execute_bridge or from a quote's steps[].requestId') and contextualizing its use in the workflow. This enhances understanding beyond the schema's basic type information.
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 explicitly states the tool's purpose as 'Check the status of a Relay bridge or swap transaction' with the specific verb 'check' and resources 'Relay bridge or swap transaction'. It clearly distinguishes from siblings like get_transaction_history (which retrieves past transactions) and execute_bridge (which initiates transactions).
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 usage guidance: it specifies when to use ('Use the requestId returned from execute_bridge'), when not to use (the user does NOT need to do anything else after execution completes), and alternatives (implied that other tools like execute_bridge or get_bridge_quote are for different purposes). It also includes polling frequency advice ('Poll every 5-10 seconds').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect a user's wallet via WalletConnect. The user scans a QR code with their mobile wallet (MetaMask, Rainbow, etc.) to approve transactions — private keys never leave their device.
Actions: pair — Returns a WalletConnect URI. You MUST then display it as a QR code (see below), then IMMEDIATELY call status to wait for connection. status — Waits up to 60s for the wallet to connect. Blocks until connected or timeout. Call this right after rendering the QR. execute — Execute ALL steps from execute_bridge in order. Handles multi-step flows (approval + deposit) and both transaction and signature steps automatically. disconnect — End the wallet session.
IMPORTANT: After calling pair, you must:
Render the returned URI as a QR code using the bash command below.
Immediately call wallet with action 'status' — it will block until the user scans and connects (up to 60s).
Run this bash command to render the QR as an image, substituting the URI:
python3 -c " import qrcode, tempfile, os qr = qrcode.QRCode(border=3, box_size=10, error_correction=qrcode.constants.ERROR_CORRECT_L) qr.add_data('WALLETCONNECT_URI_HERE') qr.make() img = qr.make_image(fill_color='black', back_color='white') p = os.path.join(tempfile.gettempdir(), 'relay-wc-qr.png') img.save(p) os.system(f'open {p}') print(f'QR code opened: {p}') "
If python3 qrcode is not installed, run: pip3 install "qrcode[pil]"
Typical flow: pair → render QR via bash → (user scans) → status → execute_bridge → execute → get_transaction_status
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The wallet action to perform. | |
| chainIds | No | Chain IDs to request access to. Required for "pair". E.g. [1, 8453] for Ethereum + Base. | |
| steps | No | The steps array from execute_bridge. Required for "execute". Contains all steps (approval, deposit, signatures) to execute in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behaviors: the 60-second timeout for status, that execute handles multi-step flows automatically, that private keys never leave the device, and the blocking nature of status. It could improve by mentioning error handling or rate limits.
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 front-loaded with purpose and actions, but includes lengthy bash command examples and installation instructions that could be separated. While informative, some sections (like the full python code) are verbose for a tool description.
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 complex tool with 3 parameters, no annotations, and no output schema, the description provides substantial context: workflow sequences, parameter requirements, behavioral details, and integration instructions. It lacks explicit output descriptions but compensates with procedural guidance.
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 baseline is 3. The description adds value by explaining when parameters are required (chainIds for 'pair', steps for 'execute') and providing context about the steps array ('Contains all steps to execute in order'), elevating it above baseline.
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: 'Connect a user's wallet via WalletConnect' with specific actions (pair, status, execute, disconnect). It distinguishes from sibling tools by focusing on wallet connection and transaction execution rather than quoting, estimating, or querying data.
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 usage guidelines including a 'Typical flow' section (pair → render QR → status → execute_bridge → execute → get_transaction_status), when to call each action, and prerequisites like requiring chainIds for 'pair' and steps for 'execute'. It also specifies the critical sequence after calling pair.
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.
v0.1.0estimate_feesexecute_bridgeget_bridge_quoteget_relay_app_urlget_supported_chainsget_supported_tokensget_swap_quoteget_transaction_historyget_transaction_statuswalletEach tool has a distinct purpose with clear boundaries. For example, estimate_fees is for cost estimation only, execute_bridge handles transaction preparation, get_bridge_quote and get_swap_quote are for different quote types, and wallet manages wallet connections and execution. No tools appear to overlap or cause confusion.
All tool names follow a consistent verb_noun pattern using snake_case, such as estimate_fees, execute_bridge, get_transaction_status, and wallet. The naming is predictable and uniform across all 10 tools, making them easy to identify and use.
With 10 tools, the server is well-scoped for its purpose of handling cross-chain bridges and swaps. Each tool serves a specific role in the workflow, from setup (get_supported_chains, get_supported_tokens) to execution (execute_bridge, wallet) and monitoring (get_transaction_status, get_transaction_history), with no redundant or missing tools.
The toolset provides complete coverage for the domain of cross-chain transactions. It includes setup tools for chains and tokens, quote and fee estimation tools, execution and wallet management tools, and monitoring tools for status and history. There are no obvious gaps, and the tools support the full lifecycle from preparation to completion.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
Li.Fi tools over MCP: cross-chain quotes, routes, execution status, chains, tokens, balances.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/relayprotocol/relay-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
