Cross-chain route optimizer for AI agents: compares LI.FI and Across quotes across Ethereum, Base, Arbitrum, Optimism and Polygon, computes net received value in USD, filters unsafe routes and returns the best route with alternatives. Non-custodial; pay per call with x402 (USDC on Base).
Scored across 1 tool
With a single tool there is no possible misselection between tools, so distinctness is trivially satisfied. The tool itself clearly scopes one action: quote and rank cross-chain routes.
The name follows a clear snake_case verb_noun convention (quote_cross_chain_route) that reads well and is predictable. A single name cannot demonstrate a repeatable pattern, so it falls short of a 5.
One tool for a whole bridging server is very thin; a quote-only surface leaves the agent with no way to act on the quote. The tool is useful but the set does not earn a well-scoped toolbelt.
Only route quoting is covered: there is no transaction building/execution, no transfer status tracking, and no chain/token enumeration. An agent can compare routes but will hit a dead end when it needs to actually bridge or confirm a transfer.
Cross-chain bridge route quotes: compares LI.FI and Across for EVM transfers (Ethereum, Base, Arbitrum, Optimism, Polygon), computes net received value in USD, filters unsafe routes and ranks the best one with alternatives. Quote only, non-custodial.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Integer amount in the token smallest unit (USDC has 6 decimals: 100 USDC = "100000000"). | |
| sender | No | Optional sender EVM address (improves quote accuracy). | |
| providers | No | Optional subset of providers to query. | |
| recipient | No | Optional recipient EVM address (defaults to sender). | |
| constraints | No | ||
| source_chain | Yes | Chain key (ethereum, base, arbitrum, optimism, polygon) or numeric chain id. | |
| source_token | Yes | Token symbol from GET /v1/assets (e.g. USDC, ETH) or token contract address. | |
| max_alternatives | No | ||
| selection_policy | No | highest_net_output | |
| destination_chain | Yes | Chain key (ethereum, base, arbitrum, optimism, polygon) or numeric chain id. | |
| destination_token | Yes | Token symbol or contract address on the destination chain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety baseline is covered. The description adds real value beyond that: non-custodial, quote-only, and that it filters unsafe routes and ranks alternatives. It stops short of describing return format or any rate-limit behavior, but with no output schema the ranking claim is a useful behavioral signal.
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?
A single front-loaded sentence with no filler; the scope and the 'quote only' caveat arrive first. It is dense rather than bloated, though the final 'non-custodial' could arguably be folded earlier.
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 an 11-parameter, nested-object, read-only quoting tool with no output schema, the description covers what the tool does, which chains/providers it touches, and that it ranks results with alternatives. The main gap is that the nested constraints object and the shape of the returned quote are not described anywhere.
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 73% and the schema documents most parameters well, including the amount decimals rule and chain keys. The description only adds that providers are LI.FI/Across and which chains are supported; it says nothing about the nested constraints object (max_slippage_bps, require_executable, max_value_loss_bps), which the schema also under-documents. Baseline 3 is appropriate.
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?
States a specific resource (cross-chain bridge route quotes) and concrete actions: compares LI.FI and Across, computes net received value in USD, filters unsafe routes, ranks the best. Named chains and providers make the scope unambiguous. No siblings exist, so no differentiation is needed, but the sentence is heavy with multiple verbs.
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?
'Quote only, non-custodial' clearly bounds usage: this returns a quote and does not execute the bridge, which is the key when-not guidance. It does not state prerequisites (e.g., that a sender address improves accuracy) or what to do after receiving a quote, and there are no sibling tools to route against.
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.
quote_cross_chain_route
Add one secure layer between your agents and this server.