Best cross-chain bridge routes via LI.FI -- 60+ chains, 18+ bridges, fees and time compared.
Single tool 'bridge_find_best_route' has a well-structured input schema with 5 parameters (4 required, 1 optional), all with type definitions and descriptions. The tool description is comprehensive (380+ chars) and includes usage guidance, examples, and anti-patterns (when NOT to use). However, the description embeds example output JSON inline rather than documenting the output schema formally. Parameter descriptions are adequate but could be more precise (e.g., 'Source chain ID' lacks clarity on whether numeric IDs or names are accepted). No error handling guidance is present, the tool does not document what happens on invalid chains, insufficient liquidity, or API failures. The tool follows verb_noun naming ('bridge_find_best_route') but is slightly verbose; 'find_bridge_route' would be more concise. Overall, the tool is above-average for a single-tool server but lacks formal output schema documentation and error recovery patterns.
Use this when you need to bridge tokens between different blockchains. Returns ranked bridge routes with fees and timing in JSON. 1. routes: array of bridge options ranked by best value 2. bridgeProvider: which bridge protocol (Stargate, Across, Hop, Connext, etc.) 3. estimatedTime: expected bridge completion time in seconds 4. fee: total bridging fee in USD 5. amountReceived: expected output amount on destination chain 6. steps: detailed step-by-step route (approve, bridge, swap if needed) Example output: {"routes":[{"bridgeProvider":"Stargate","estimatedTime":60,"fee":0.85,"amountReceived":"999.15","steps":["approve USDC","bridge via Stargate"]}],"fromChain":"Ethereum","toChain":"Base","token":"USDC"} Use this BEFORE moving assets cross-chain to find the cheapest and fastest bridge. Essential for multi-chain portfolio management. Do NOT use for same-chain swaps -- use dex_get_swap_quote instead. Do NOT use for gas prices -- use gas_get_current_price instead. Do NOT use for multi-chain gas comparison -- use crypto_estimate_gas instead.
Output schema not formally documented. Example JSON is embedded in the description, but the tool does not declare a structured output schema with field types and descriptions. LLMs cannot reliably extract fields like 'routes', 'bridgeProvider', 'estimatedTime', 'fee', 'amountReceived', 'steps' without a formal schema.
No error handling guidance. The tool description does not explain what happens if fromChain/toChain are invalid, if the token is not supported, if liquidity is insufficient, or if the bridge API is unavailable. LLMs have no recovery path.
Chain ID parameter format ambiguous. Description says 'Source chain ID (1=Ethereum, 8453=Base, ...)' but does not clarify whether the tool accepts numeric strings ('1'), integers (1), or chain names ('ethereum'). This forces LLMs to guess.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2025-06-18+ | v2 |
Amount parameter format requires smallest unit but lacks validation guidance. Description says 'Amount in smallest unit (e.g. 1000000 for 1 USDC with 6 decimals)' but does not document what happens if the LLM passes a decimal (1.5) or a string with commas. No validation error message template provided.
toToken parameter optional but no guidance on default behavior. Description says 'optional, defaults to same as token' but does not explain what happens if the destination chain does not support the same token symbol (e.g., bridging USDC from Ethereum to a chain that only has USDT).