Provides tools for cross-chain bridging, token swapping, and real-time price discovery on the Ethereum network.
Enables cross-chain bridging, multi-chain token swaps, and real-time price monitoring for the Optimism blockchain network.
Facilitates cross-chain bridging and token swaps on the Polygon network, including price discovery and transaction status tracking.
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 Protocol MCP Server Get a quote to bridge 100 USDC from Ethereum to Polygon"
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.
Model Context Protocol (MCP) server for the Relay Protocol REST API enabling cross-chain bridging and token swapping operations.
Cross-Chain Bridging - Bridge tokens between 50+ blockchain networks
Multi-Chain Swaps - Aggregate tokens from multiple chains into single destination
Real-Time Pricing - Get current token prices across all supported chains
Request Monitoring - Track execution status and transaction details
Currency Discovery - Browse 1000+ supported tokens with filtering
Zero Configuration - No API keys required (free public API)
Type Safety - Full TypeScript support with comprehensive validation
Related MCP server: deBridge MCP Server
# Install and build
pnpm install && pnpm build
# Run development server
pnpm dev
# Run production server
pnpm startDeploy to Railway, Heroku, Render, or any cloud platform:
# Build the server
pnpm build
# Start SSE server (uses PORT from environment or 3000)
pnpm start:sse
# Or for development
pnpm dev:sseSee RAILWAY.md for detailed Railway deployment guide.
Add to your Claude Desktop configuration file:
Config Location:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"Relay Protocol": {
"command": "node",
"args": ["/absolute/path/to/relay-protocol-mcp-server/dist/index.js"]
}
}
}Deploy Steps:
Push your code to GitHub
Go to railway.app → "New Project" → "Deploy from GitHub repo"
Select your repository (Railway auto-detects configuration)
Get your deployment URL: https://your-app.railway.app
Claude Desktop Configuration:
{
"mcpServers": {
"Relay Protocol": {
"transport": "sse",
"url": "https://your-app.railway.app/sse"
}
}
}Test Your Deployment:
curl https://your-app.railway.app/health
# Response: {"status":"healthy","server":"Relay Protocol","version":"0.1.0","transport":"sse"}Deployment Info:
Free tier: $5/month credits (plenty for personal use)
Memory usage: ~50-100MB RAM
Auto-sleeps after 30 minutes of inactivity
Railway CLI: npm i -g @railway/cli (optional)
Tool | Purpose | Example Use Case |
| List supported blockchain networks | "Show me all chains Relay supports" |
| Get real-time token prices | "What's the price of USDC on Ethereum?" |
| Discover tokens with advanced filtering | "Show verified tokens on Arbitrum" |
| Generate bridging/swap quotes | "Quote bridging 100 USDC from Ethereum to Polygon" |
| Execute multi-chain swaps | "Swap ETH + USDC from multiple chains to USDC on Base" |
| Track request progress | "Check status of my bridge transaction" |
| Monitor request history | "Show my recent cross-chain transactions" |
| Index transactions for tracking | "Register this transaction for monitoring" |
| Index specific transfers/wraps | "Track this specific transfer operation" |
# Bridge tokens
"Bridge 100 USDC from Ethereum to Polygon"
"What chains can I bridge USDC between?"
# Multi-chain swaps
"Swap all my USDC from Ethereum and Polygon to ETH on Arbitrum"
"Consolidate my tokens from multiple chains into USDC on Base"
# Price discovery
"Show current ETH prices across all chains"
"What's the cheapest way to get USDC on Optimism?"
# Currency discovery
"Find all stablecoins available on Polygon"
"Show me verified tokens with bridging support"pnpm typecheck # Type checking
pnpm dev # Development with auto-reload
pnpm build # Production build
pnpm start # Start production serversrc/
├── client/ # HTTP client and error handling
├── tools/ # 9 MCP tool implementations
├── types/relay.ts # Complete TypeScript definitions
├── config.ts # API configuration
├── index.ts # Stdio transport (local)
└── server.ts # SSE transport (cloud)"No available tools" in Claude:
Verify absolute path in config is correct
Test server: echo '{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}' | node dist/index.js
Restart Claude Desktop after config changes
Ensure Node.js >= 20.0.0 and pnpm build completed
Connection issues:
Run pnpm build before starting
Check server starts without errors: pnpm dev
Verify JSON syntax in Claude config file
Node.js >= 20.0.0
pnpm package manager
Full access to Relay Protocol REST API with TypeScript types and validation. The Relay Protocol supports:
50+ Blockchain Networks including Ethereum, Polygon, Arbitrum, Optimism, Base, etc.
1000+ Tokens with real-time pricing and bridging support
Free Public API with no rate limits or authentication required
Production-Ready infrastructure handling millions in daily volume
MIT
Get all supported chains for cross-chain operations. Returns detailed information about each chain including RPC URLs, explorers, currencies, and supported tokens.
Common Chain IDs: • Ethereum: 1 • Optimism: 10 • Polygon: 137 • Arbitrum: 42161 • Base: 8453 • BNB Chain: 56
Optional: Use includeChains parameter to filter specific chains (comma-separated chain IDs).
| Name | Required | Description | Default |
|---|---|---|---|
| includeChains | No | Comma-separated list of chain IDs to include |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It indicates a read-only operation returning detailed information, but doesn't mention response size, rate limits, or potential errors.
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 succinct and front-loaded with the main purpose, followed by useful context (common IDs) and parameter usage. No extra 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 single optional parameter and no output schema, the description provides sufficient context: return content, common IDs, and filtering. Could benefit from mention of response size or limits, but adequate.
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 coverage is 100%, so baseline is 3. The description adds minimal extra value beyond the schema's parameter description, just restating the optional nature and format.
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 retrieves all supported chains with details like RPC URLs and explorers. It distinguishes itself from siblings like relay_get_currencies and provides a list of common chain IDs.
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 explains the optional filter parameter and provides common chain IDs, aiding usage. However, it doesn't explicitly state when to use this tool versus alternatives or when not to use it, though the distinct purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get currencies metadata from a curated list. Supports filtering by chain IDs, search terms, addresses, and other criteria.
Common Examples: • Find USDC on specific chains: {"chainIds": [1, 10, 8453], "term": "usdc", "verified": true, "limit": 10} • All major tokens on Ethereum: {"chainIds": [1], "defaultList": true, "limit": 20} • Search by contract address: {"address": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48", "includeAllChains": true} • Verified tokens only: {"verified": true, "limit": 50} • Deposit-address supported tokens: {"depositAddressOnly": true}
Tip: Use verified=true to avoid scam/fake tokens. Use term to search by symbol/name.
| Name | Required | Description | Default |
|---|---|---|---|
| defaultList | No | Return default currencies from curated list | |
| chainIds | No | Chain IDs to search for currencies (e.g., [1, 10, 137] for Ethereum, Optimism, Polygon) | |
| term | No | Search term for currencies (symbol, name, or partial match) | |
| address | No | Token contract address to search for | |
| currencyId | No | Specific currency ID to retrieve | |
| tokens | No | List of token identifiers in format chainId:address (e.g., ["1:0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48"]) | |
| verified | No | Filter for verified currencies only (recommended to avoid scam tokens) | |
| limit | No | Limit the number of results (default: 20, max: 100) | |
| includeAllChains | No | Include all chains for a currency when filtering by chainId and address | |
| useExternalSearch | No | Use 3rd party APIs to search for tokens not indexed by Relay | |
| depositAddressOnly | No | Return only currencies supported with deposit address bridging |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It mentions a 'curated list' and 'defaultList' but does not disclose behavioral details such as data source, rate limits, or response structure (e.g., returns only metadata, no live prices). Adequate but not deep.
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?
Starts with a clear one-sentence purpose, followed by well-organized examples covering diverse use cases, and ends with a succinct tip. Every sentence adds value; no filler or redundancy.
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 large number of parameters (11) and no output schema, the description covers the tool's functionality well through examples and tips. It lacks details on return format (e.g., fields like address, symbol, chain) but implies metadata retrieval. Still, it is complete enough for basic 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 coverage is 100%, so baseline is 3. Description adds value through concrete examples (e.g., how to combine chainIds, term, verified) and a tip on using verified=true. This goes beyond the schema's individual parameter descriptions by showing practical combinations.
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?
Description clearly states 'Get currencies metadata' with a specific verb and resource. It distinguishes from sibling tools like relay_get_chains (chains) and relay_get_token_price (price) by focusing on currency metadata. Examples reinforce the purpose.
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?
Provides clear examples of when to use various filtering options (chainIds, term, address, verified, etc.) and includes a tip to use verified=true to avoid scam tokens. However, it does not explicitly state when not to use this tool or compare with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current execution status of a cross-chain request. Returns status, transaction hash, and other execution details.
When to use: After executing a quote/swap, use the requestId from the response to monitor progress. Request ID format: Hex string starting with "0x" (e.g., "0x1234abcd...") Status values: "pending", "success", "failed", "insufficient-balance"
Example workflow: relay_get_quote → get requestId → relay_get_execution_status
| Name | Required | Description | Default |
|---|---|---|---|
| requestId | Yes | The ID of the cross-chain request to check status for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description explains returns (status, tx hash) and lists possible status values. Transparent about being a read-only status check.
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?
Very concise: single sentence for purpose, then bullet-like structured info. 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?
Covers purpose, usage context, status values, and example workflow. Lacks output schema but mentions key return fields. Adequate for a simple status polling tool.
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 has 100% coverage; description adds format (0x hex string) beyond schema's description, aiding correct invocation.
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?
Clearly states the tool gets execution status of a cross-chain request. Differentiates from siblings (quote, chains, etc.) by focusing on status after 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?
Explicitly says when to use (after executing quote/swap with requestId). Provides example workflow. Lacks explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an executable quote for bridging tokens between chains or swapping within a chain. Always use TOKEN CONTRACT ADDRESSES, not symbols. Use relay_get_currencies to find token addresses.
Common Examples: • Bridge USDC Ethereum→Optimism: user="0x123...", originChainId=1, destinationChainId=10, originCurrency="0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48", destinationCurrency="0x0b2c639c533813f4aa9d7837caf62653d097ff85", amount="1000000", tradeType="EXACT_INPUT" • Bridge USDC Ethereum→Base: originChainId=1, destinationChainId=8453, destinationCurrency="0x833589fcd6edb6e08f4c7c32d4f71b54bda02913" • Same-chain swap on Ethereum: originChainId=1, destinationChainId=1, different token addresses
Token Format: Always use contract addresses (checksummed preferred) Amount Format: Smallest unit - "1000000"=1 USDC, "1000000000000000000"=1 ETH
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | User wallet address | |
| recipient | No | Recipient wallet address (defaults to user address) | |
| originChainId | Yes | Source chain ID (e.g., 1 for Ethereum, 10 for Optimism, 8453 for Base) | |
| destinationChainId | Yes | Destination chain ID | |
| originCurrency | Yes | Source token contract address (e.g., "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48" for USDC on Ethereum) | |
| destinationCurrency | Yes | Destination token contract address (e.g., "0x0b2c639c533813f4aa9d7837caf62653d097ff85" for USDC on Optimism) | |
| amount | Yes | Amount in smallest unit (e.g., "1000000" = 1 USDC with 6 decimals, "1000000000000000000" = 1 ETH) | |
| tradeType | No | Trade type: EXACT_INPUT (specify input amount), EXACT_OUTPUT (specify exact output), EXPECTED_OUTPUT (expected output) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains the tool returns an executable quote and covers token/amount formats, but does not disclose side effects, auth needs, or safety (e.g., read-only nature is implied but not stated). The description adds context but falls short of full behavioral transparency.
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 a clear main sentence, followed by examples and bullet points. It is front-loaded and each part serves a purpose. Could be slightly more concise in the examples section, 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 (cross-chain bridging, 8 parameters), the description covers purpose, format rules, examples, and trade types. It lacks details on what the quote includes (e.g., fees, slippage), but is otherwise complete for a quote retrieval tool.
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% coverage, so baseline is 3. The description adds value by providing examples, clarifying token and amount formats in smallest units, and explaining tradeType enum values. This goes beyond the schema's property descriptions.
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 gets an executable quote for bridging or swapping tokens. It uses specific verb 'Get an executable quote' and distinguishes from siblings by mentioning cross-chain and same-chain scenarios, and references relay_get_currencies for token addresses.
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: always use contract addresses, use relay_get_currencies to find addresses, and gives common examples. However, it does not explicitly state when not to use this tool or suggest alternatives for different tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all cross-chain transactions with advanced filtering and pagination.
Use Cases: • List all transactions for a specific user • Find transactions by hash, chain IDs, or time range • Monitor transaction history with pagination • Filter by request status and referrer
Pagination: Use limit (max 50) and continuation token for large result sets. Sorting: Sort by createdAt or updatedAt in asc/desc order.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Limit the number of results (1-50, default: 20) | |
| continuation | No | Continuation token for pagination | |
| user | No | Filter by user address | |
| hash | No | Filter by transaction hash | |
| originChainId | No | Filter by origin chain ID | |
| destinationChainId | No | Filter by destination chain ID | |
| privateChainsToInclude | No | Private chains to include | |
| id | No | Filter by request ID | |
| startTimestamp | No | Start timestamp filter (Unix timestamp) | |
| endTimestamp | No | End timestamp filter (Unix timestamp) | |
| startBlock | No | Start block filter | |
| endBlock | No | End block filter | |
| chainId | No | Filter by chain ID (either direction, overrides origin/destination filters) | |
| referrer | No | Filter by referrer address | |
| sortBy | No | Sort field (default: createdAt) | |
| sortDirection | No | Sort direction |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses pagination behavior, sorting options, and filtering capabilities. Does not mention side effects (expected read-only) or authentication, but adequate for a query 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?
Description is highly concise with front-loaded purpose, followed by bullet-pointed use cases and clear pagination/sorting notes. Every sentence adds value.
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 16 parameters and no output schema, the description covers main use cases, pagination, and sorting. It does not detail return format, but schema descriptions fill in parameter details. Sufficient for an agent to select and invoke.
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. Description adds grouping of use cases and mention of pagination/sorting, but does not provide additional meaning for individual parameters beyond what the schema already describes.
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?
Description clearly states 'Get all cross-chain transactions with advanced filtering and pagination,' providing specific verb and resource. Use cases differentiate it from sibling tools like relay_get_chains and relay_get_currencies.
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?
Use cases are listed explicitly (listing for user, finding by hash, monitoring history, filtering by status). Pagination and sorting are mentioned. However, no guidance on when not to use or comparisons to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current price of a token on a specific chain. Requires the token contract address, not symbol. Use relay_get_currencies to find token addresses.
Examples: • USDC on Ethereum: chainId=1, address="0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48" • WETH on Optimism: chainId=10, address="0x4200000000000000000000000000000000000006" • USDC on Base: chainId=8453, address="0x833589fcd6edb6e08f4c7c32d4f71b54bda02913"
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | Yes | The chain ID where the token exists (e.g., 1 for Ethereum, 10 for Optimism) | |
| address | Yes | The token contract address (e.g., "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48" for USDC on Ethereum) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description does not disclose read-only nature, error handling, rate limits, or auth needs. Only mentions input constraints.
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 plus examples, front-loaded purpose, no waste—every sentence earns its place.
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?
No output schema or annotations; description covers inputs well but omits return format, errors, or behavioral traits, leaving 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?
Schema has 100% coverage. Description adds examples and warns against using symbol, but adds minimal semantics beyond schema.
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 it gets the current price of a token on a specific chain, using contract address not symbol, distinguishing it from other relay tools.
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?
Clear context: prints when to use (price lookup) and hints at when not (if missing address), referencing relay_get_currencies. Lacks explicit when-not or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute multi-chain token swaps. IMPORTANT: For EXACT_INPUT, do NOT include "amount" at root level - only in origins array. For EXACT_OUTPUT, include "amount" at root level. Always use TOKEN CONTRACT ADDRESSES. Examples:
EXACT_INPUT (Bridge 1 USDC from Ethereum to Optimism): {"user": "0x123...", "origins": [{"chainId": 1, "currency": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48", "amount": "1000000"}], "destinationChainId": 10, "destinationCurrency": "0x0b2c639c533813f4aa9d7837caf62653d097ff85", "tradeType": "EXACT_INPUT"}
EXACT_OUTPUT (Get exactly 100 USDC on Base): {"user": "0x123...", "amount": "100000000", "origins": [{"chainId": 1, "currency": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48", "amount": "50000000"}], "destinationChainId": 8453, "destinationCurrency": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913", "tradeType": "EXACT_OUTPUT"}
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | User wallet address that will make deposits and receive tokens | |
| origins | Yes | Array of origin tokens to swap from multiple chains | |
| destinationCurrency | Yes | Destination token contract address (e.g., "0x0b2c639c533813f4aa9d7837caf62653d097ff85" for USDC on Optimism) | |
| destinationChainId | Yes | Destination chain ID (e.g., 10 for Optimism, 8453 for Base, 42161 for Arbitrum) | |
| tradeType | Yes | EXACT_INPUT: Use exact amounts from origins. EXACT_OUTPUT: Get exact amount at destination (requires "amount" field) | |
| recipient | No | Optional: recipient address (defaults to user address) | |
| refundTo | No | Optional: refund address in case of failure | |
| amount | No | ONLY for EXACT_OUTPUT: exact amount to receive at destination (in smallest unit) | |
| txs | No | Optional: additional transactions to execute | |
| txsGasLimit | No | Gas limit for additional transactions | |
| partial | No | Allow partial fills if full amount not available | |
| referrer | No | Referrer address for fee sharing | |
| gasLimitForDepositSpecifiedTxs | No | Gas limit for deposit-specified transactions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose whether the tool is read-only or destructive, nor does it mention transaction costs, gas implications, or failure behavior. The examples imply it submits a transaction, but this is not explicitly stated.
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?
Well-structured: general description, important notes, then two clear examples. No wasted sentences; every part earns its place. Examples are concise yet informative.
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?
Covers core swap logic but does not explain return value (e.g., transaction hash or status), error handling, or prerequisites (e.g., approvals, balance). With no output schema, this omission limits completeness for a complex tool.
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 coverage is 100%, but description adds significant value by explaining the trade-type-specific parameter rules (amount placement) and providing complete examples. This clarifies ambiguous usage beyond the schema.
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?
Clearly states it executes multi-chain token swaps. Distinguishes from sibling tools like relay_get_quote and relay_get_chains, which are for querying or quoting, not 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?
Provides explicit guidance on EXACT_INPUT vs EXACT_OUTPUT, including the crucial 'amount' field placement and token contract addresses. Lacks explicit alternatives or exclusions, but context from siblings implies this is for execution after quoting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Notify the Relay backend about a transaction. This is used to index and track transactions for cross-chain operations.
When to use: • After executing a transaction from a quote response • When you want Relay to track a specific transaction • For proper status monitoring and request linking
Example: After sending the deposit transaction from relay_get_quote response, call this tool with the transaction hash and chain ID to enable proper tracking.
Required: txHash (0x...), chainId (number) Optional: requestId (from quote response for linking)
| Name | Required | Description | Default |
|---|---|---|---|
| txHash | Yes | Transaction hash to index | |
| chainId | Yes | Chain ID where the transaction occurred (as string, e.g., "1" for Ethereum, "10" for Optimism) | |
| requestId | No | Optional request ID to associate with the transaction |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose whether the tool is destructive, idempotent, or requires special permissions, nor does it mention potential side effects 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 well-organized with section headers, bullet points, and a concrete example. Every sentence adds value and no unnecessary text is present.
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?
While the description covers usage and parameters well, it lacks information about return values and error handling. Given no output schema, the agent might need more context on what to expect from the tool.
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 coverage is 100%, but the description adds context beyond the schema (e.g., example format for txHash, explanation of requestId linking). This helps the agent understand parameter usage in context.
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 ('Notify the Relay backend about a transaction') and its use for indexing and tracking transactions. It distinguishes from siblings by focusing on post-execution notification.
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 'when to use' bullet points and an example, but does not include when not to use or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Notify the Relay backend to index transfers, wraps and unwraps for a specific transaction.
When to use: • Index specific transfers within a transaction • Track wrap/unwrap operations • Associate transaction data with a request ID
Difference from relay_transactions_index: • This is for indexing specific transfers/wraps/unwraps • relay_transactions_index is for general transaction tracking
Required: requestId, chainId (string), tx (transaction hash)
| Name | Required | Description | Default |
|---|---|---|---|
| requestId | Yes | Request ID to associate with the transaction | |
| chainId | Yes | Chain ID where the transaction occurred (as string, e.g., "1" for Ethereum, "10" for Optimism) | |
| tx | Yes | Transaction hash to index (0x...) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a mutation (indexing) and lists all required parameters. However, it does not disclose side effects, idempotency, or error handling. With no annotations, it carries the burden but falls slightly short of full transparency.
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 a clear purpose sentence followed by bullet points. It is concise but the repeated required fields line is slightly redundant given the schema.
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?
While the description covers usage and differentiation, it omits details about the return value or what happens after indexing (e.g., no output schema). For a 3-parameter tool with high schema coverage, this is adequate but not 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 coverage is 100%, so baseline is 3. The description repeats parameter names and requirements (e.g., 'Required: requestId, chainId, tx') but adds minimal new semantic value beyond explaining their role in context.
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 'Notify...to index' and specifies the resource: transfers, wraps, and unwraps. It distinguishes from the sibling relay_transactions_index, making the purpose unambiguous.
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?
Provides explicit 'When to use' bullet points and a 'Difference from relay_transactions_index' section, offering clear guidance on context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are mostly distinct with clear purposes. Slight overlap between get_execution_status and get_requests (both provide status info) and between transactions_index and transactions_single, but descriptions help differentiate.
Naming follows a consistent 'relay_' prefix, but verbs are mixed: 'get_' tools are verb_noun, while 'swap_multi_input' and 'transactions_index'/'transactions_single' deviate from that pattern, causing inconsistency.
9 tools is appropriate for the cross-chain swap domain. Each tool covers a distinct step in the workflow without being excessive or insufficient.
Core workflows (discover chains/tokens, get quotes, execute swaps, monitor status) are well-covered. Minor gaps like token approval management are absent but not critical for basic operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query real-time blockchain token data across EVM and Solana networks. Access token balances, transfers, prices, holders, NFT ownership, DEX swaps, and liquidity pools. Supports Ethereum, Base, Arbitrum, BSC, Polygon, Solana, and more.
Doc search, intent & cross-chain swaps, limit orders, portfolio, spot prices, gas & all APIs.
Non-custodial value router: ranked fiat/crypto & cross-chain routes, swaps, onramp, gasless wallet.
Token swaps and honeypot/rug checks for AI agents on 8 chains, paid per-call in USDC via x402.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/warengonzaga/relay-protocol-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
