Enables finding LayerZero OFT bridge routes and building cross-chain transactions involving Arc, including route resolution and ready-to-sign transaction generation.
Enables finding LayerZero OFT bridge routes and building cross-chain transactions involving BNB Chain, including support for tokens not listed on aggregators.
Click on "Deploy 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., "@Galactic Bridge MCP bridge 50 of 0x90e7...d9e1 from BNB Chain to Arc for 0xABC..."
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.
An MCP server that lets AI agents and MCP clients (Claude Desktop, Cursor, …) use Galactic Bridge to find LayerZero OFT bridge routes by token contract address and build ready-to-sign cross-chain transactions across 14 EVM networks — including tokens that aren't listed on aggregators like Stargate.
By default this server is read-only. It finds routes and builds transactions, but it never holds a key and never signs anything — a human or wallet does that. Auto-signing is an optional add-on you turn on yourself (see the bottom).
It talks only to the public Galactic Bridge API — the same endpoints the website calls. It does not run on the bridge's servers and changes nothing there.
Tool | What it does |
| The 14 networks, with chain key, chainId, LayerZero eid and native symbol. |
| Given a token address, every network it exists on and its OFT contract on each. |
| Resolves a route between two networks: OFT contract, whether the direction is enabled right now, the fee, and — with |
find_bridge_route never signs or sends. It returns transaction objects
({ to, data, value, chainId }) for you to review and sign in your own wallet.
Related MCP server: Universal Crypto MCP
Requires Node.js 18+.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"galactic-bridge": {
"command": "npx",
"args": ["-y", "galactic-bridge-mcp"]
}
}
}Point the client at the command npx -y galactic-bridge-mcp (stdio transport).
git clone https://github.com/mckellen-eth/galactic-bridge-mcp.git
cd galactic-bridge-mcp
npm install
npm run build
node dist/index.js"Bridge 50 of token 0x90e7…d9e1 from BNB Chain to Arc, to my address 0xABC…"
The agent calls find_bridge_route and gets back a ready transaction plus the
fee. You review it and sign in your wallet. If the token uses a separate adapter,
you'll also get an approval transaction to sign first.
No keys by default. The read-only tools never see a private key.
You sign. Transactions are returned for review; your wallet signs them.
Fees and decimals are read live, so amounts are exact. Directions that a token has disabled are reported instead of returning a transaction that would revert.
Always verify a transaction before signing. This software is provided as-is, with no warranty (MIT).
You can let the server sign and broadcast transactions itself by setting a private key in your environment. This moves real funds irreversibly and is off by default. Only enable it if you understand the risk, and use a dedicated hot wallet that holds no more than you can afford to lose.
{
"mcpServers": {
"galactic-bridge": {
"command": "npx",
"args": ["-y", "galactic-bridge-mcp"],
"env": {
"GB_PRIVATE_KEY": "0xyourHotWalletKey"
}
}
}
}When GB_PRIVATE_KEY is set, an extra tool appears — execute_bridge — which
builds, signs and broadcasts the bridge transaction (and the approval first, if
needed). It needs the optional ethers package (npm install ethers) and, for
networks without a built-in public RPC, an override like GB_RPC_BSC=….
Without GB_PRIVATE_KEY, none of this loads and the server stays read-only.
Variable | Purpose |
| Override the bridge API base URL (default |
| Opt in to auto-signing. Unset = read-only. |
| RPC URL used by auto-signing for that chain (e.g. |
Resolve the bridge route for a token between two networks: the OFT contract, whether the direction is enabled right now, the fee, and — if amount and recipient are given — a ready-to-sign transaction (plus an ERC-20 approval transaction when the token bridges through a separate adapter). This tool NEVER signs or sends; it returns transactions for a human or wallet to review and sign.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token contract address (0x…). | |
| amount | No | Human-readable amount to bridge, e.g. "12.5". Required to build a transaction. | |
| toChain | Yes | Destination network key (e.g. "arc"). | |
| decimals | No | Token decimals. Read automatically if omitted; pass explicitly to be certain. | |
| fromChain | Yes | Source network key (e.g. "bsc"). See list_supported_networks. | |
| recipient | No | Recipient address on the destination network (also the refund address). Required to build a transaction. | |
| oftContract | No | Optional: the OFT contract address, if you already know it (skips discovery). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does a good job: it explicitly says the tool never signs or sends and returns transactions for review, and it discloses that direction availability is checked 'right now' and that an ERC-20 approval may be included. It does not cover every possible failure mode or state that it is read-only in those exact words, but the core behavioral risk is well addressed.
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 no filler. It front-loads the core purpose and outputs, then adds the critical safety caveat that the tool never signs or sends. Every clause 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?
Given the 7-parameter schema, no annotations, and no output schema, the description is reasonably complete: it names the main return elements (OFT contract, direction, fee, transaction, approval transaction) and the no-execution behavior. It does not fully specify the transaction object's structure or how omitted amount/recipient affects the response beyond implication, so it is strong but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the schema already explains token, fromChain, toChain, amount, recipient, decimals, and oftContract. The description adds useful relational context about when a transaction is built and when an approval transaction appears, but it does not materially deepen individual parameter meaning 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?
The description uses a specific verb ('Resolve') and a precise resource ('bridge route for a token between two networks'), listing concrete outputs such as the OFT contract, direction-enabled status, fee, and transaction. It is clearly distinguishable from siblings like list_supported_networks, but it never explicitly names or contrasts them, so it stops short of a 5.
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 clearly conveys when a transaction is produced ('if amount and recipient are given') and the tool's non-executing role ('NEVER signs or sends; it returns transactions for a human or wallet to review and sign'). It does not explicitly route users to sibling alternatives, but the purpose is specific enough that usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the EVM networks Galactic Bridge supports, with their chain key, chainId, LayerZero endpoint id (eid) and native gas symbol. Use the key values when calling the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'List' implies a read-only operation, but it does not explicitly state safety, side effects, or any limitations such as pagination or error behavior. The output fields are described, but behavioral traits beyond the core function are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that names the action, scope, and output fields, then appends a practical usage hint. There is zero waste and the essential information is immediately available.
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 zero-parameter list tool with no output schema, the description fully covers what is returned (with specific fields) and how to use the results (key values for other tools). No additional context is necessary for an agent to call it correctly.
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 tool has zero parameters, and the schema coverage is 100% (trivially empty). The baseline for 0 params is 4, and the description adds no parameter-related meaning because none exist. No compensation is needed.
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 states a specific verb ('List'), a specific resource ('EVM networks Galactic Bridge supports'), and enumerates the output fields (chain key, chainId, eid, native gas symbol). It clearly distinguishes itself from siblings like scan_token_networks and find_bridge_route, which serve different 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?
It gives clear usage context by instructing to use the `key` values when calling other tools, implying this is a precursor step. However, it does not explicitly mention when not to use it or compare it with alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a token contract address, find every supported network the token exists on and its OFT bridge contract on each. Useful to discover where a token can be bridged from and to before resolving a specific route.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The token contract address (0x…). Works on any of the supported networks. | |
| fromChain | No | Optional network key to start the scan from (e.g. "bsc"). Auto-detected if omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions that the tool scans across networks and has a 'fromChain' parameter that is auto-detected if omitted, which is useful. However, it does not disclose potential side effects (e.g., network calls, rate limits) or what happens if the token is not found. No contradiction with annotations since none exist.
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 no filler. The core purpose (what it does) is in the first sentence, and the usage context (when to use) is in the second. Every word earns its place, making it highly efficient and readable.
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 (2 params, no output schema), the description covers the purpose, usage timing, and notes auto-detection. However, it lacks details on output structure or edge cases (e.g., token not found), but these are not critical given the tool's simplicity. The availability of a sibling for route resolution adds 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?
Although the schema covers 100% of parameters with descriptions, the description adds context beyond the schema: it clarifies that 'token' is a contract address (already in schema) but also implies the tool works across all supported networks, which enriches the meaning of 'token' and the scan behavior. For 'fromChain', it explains why it's optional (auto-detected). This adds value to 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?
The description clearly states the action ('find every supported network the token exists on and its OFT bridge contract on each') with a specific resource (token contract address), and it distinguishes itself from siblings by its scope (discovery, not route resolution). The mention of 'before resolving a specific route' helps differentiate from find_bridge_route.
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 a clear usage context: 'Useful to discover where a token can be bridged from and to before resolving a specific route.' This indicates when to use this tool relative to route resolution, implying the alternative (find_bridge_route) for after discovery. However, it does not explicitly mention when not to use this tool or name the siblings directly.
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.
v0.1.0find_bridge_routelist_supported_networksscan_token_networksScored across 3 tools
Each tool addresses a distinct step in the bridge workflow: listing supported chains, discovering token deployments, and resolving a specific route. There is no meaningful overlap between the three tools.
All tool names follow a consistent snake_case verb_noun pattern: list_supported_networks, scan_token_networks, find_bridge_route. The naming style and verb usage are uniform across the set.
Three tools is a well-scoped and appropriate size for this server's purpose. Each tool covers a necessary leg of the bridge-route discovery process without redundancy.
The tool set fully covers the intended discovery workflow: knowing supported networks, locating a token on those networks, and resolving an executable bridge route. The explicit decision not to sign/send transactions is a stated boundary, not a gap.
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
Non-custodial DeFi for AI agents: swaps, concentrated liquidity (V3/V4) zaps + ranges, 5 EVM chains
Gasless cross-chain for AI agents: 25 nodes incl. Solana & native Bitcoin. One signature, no gas.
