Free non-custodial EVM swap & bridge quotes with unsigned tx; 0.25% disclosed fee on swaps
Scored across 2 tools
The two tools serve clearly separate purposes: list_swap_tokens is a discovery/metadata tool, while swap_quote produces an actual quote and unsigned transaction. There is no realistic way for an agent to confuse them.
Both names are snake_case and share the 'swap' domain vocabulary, but list_swap_tokens follows a verb_noun pattern while swap_quote is a noun compound without a verb. This is a minor deviation rather than an inconsistency.
Two tools is on the thin side, and everything funnels through a single swap_quote call. The scope is narrow enough that this is defensible, but the surface is borderline minimal.
Discovery, same-chain quotes, cross-chain bridging, fees, safety warnings, and the unsigned transaction plus approval are all covered, which matches the stated non-custodial scope. Minor gaps exist, such as no standalone approval-status check or quote refresh/status tooling, but agents can work around them.
List supported chains, chain ids, native tokens and the token symbols accepted by swap_quote (any ERC-20 address also works with amountBaseUnits).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, and the description adds the non-obvious caveat that any ERC-20 address is also valid when paired with amountBaseUnits, meaning the listed symbols are not an exhaustive set. It says nothing about rate limits or response format, but for a zero-parameter read-only lookup that is a modest gap.
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 sentence, front-loaded with the list contents and ending with the actionable caveat about ERC-20 addresses. Every clause carries information; nothing is redundant with the title or annotations.
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-arg read-only tool with no output schema, the description enumerates the fields the agent will receive (chains, chain ids, native tokens, token symbols), which is exactly the needed compensation. It stops short of describing the container format or any ordering, a minor omission given the simplicity.
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 takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description does not waste space restating an empty 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?
States a specific verb (list) and enumerates the exact resources returned: supported chains, chain ids, native tokens, and accepted token symbols. It also names the sibling tool swap_quote as the consumer of this data, so an agent can distinguish the lookup tool from the quoting tool without opening either schema.
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 tie to swap_quote ('token symbols accepted by swap_quote') makes the when-to-use context clear: consult this before quoting. It does not spell out an explicit exclusion or say 'call this first', so it falls just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Best-price token swap on one EVM chain (KyberSwap aggregator) or cross-chain bridge (LI.FI, fallback Relay; set toChain). Returns expected and minimum output, price impact, gas, every fee (MoneyTools fee: 0.25% on same-chain swaps, disclosed), safety warnings, and an UNSIGNED transaction (plus exact-amount ERC-20 approval) for your own wallet to sign. Free. Never signs or holds funds.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Source chain: ethereum, base, arbitrum, optimism, polygon, bsc, avalanche (or chain id) | |
| taker | No | Your wallet address (0x...). Needed to get an unsigned transaction; omit for a price-only quote. | |
| amount | No | Amount to sell in human units, e.g. "10" (known symbols only) | |
| toChain | No | Destination chain for a cross-chain bridge. Omit for a same-chain swap. | |
| toToken | Yes | Token to buy: symbol or 0x address (on toChain if bridging) | |
| fromToken | Yes | Token to sell: symbol (USDC, USDT, ETH, WETH, DAI, ...) or 0x address | |
| recipient | No | Receiver of the output (defaults to taker) | |
| slippageBps | No | Max slippage in basis points (50 = 0.5%, hard cap 300) | |
| allowHighImpact | No | Return the transaction even if impact exceeds maxPriceImpactPct | |
| amountBaseUnits | No | Amount in token base units (integer). Required for custom token addresses. | |
| maxPriceImpactPct | No | Withhold the transaction if estimated price impact/value loss exceeds this percent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations give readOnlyHint/openWorldHint, and the description adds substantial context: no custody, user signs the unsigned transaction, ERC-20 approval included, 0.25% fee disclosed, free, and safety behavior (transaction withheld when price impact exceeds maxPriceImpactPct unless allowHighImpact). It does not address quote expiry or rate limits, keeping it below a 5.
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?
Purpose is front-loaded in the opening clause, and the sentence stays information-dense without filler. It is packed with parentheticals and could be split for readability, but no clause is wasted.
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, no-output-schema tool, the description usefully enumerates what comes back (expected/min output, price impact, gas, fees, warnings, unsigned tx, approval). Missing only edge-case behavior such as quote expiration or failure modes (no route, insufficient liquidity).
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 the schema already documents all 11 parameters thoroughly. The description only reinforces a few of them (toChain mode switching, taker requirement for a transaction) without adding syntax or constraints the schema doesn't already contain; baseline 3 applies.
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 verb and resource ('token swap', 'cross-chain bridge') plus the routing providers (KyberSwap, LI.FI, Relay) and the parameter that selects mode ('set toChain'). An agent can immediately tell this is a quote/transaction-builder, distinct from a token-listing sibling.
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 conditional guidance: set toChain for bridging, omit it for same-chain; omit taker for a price-only quote. It lacks any reference to the sibling list_swap_tokens (e.g., 'use list_swap_tokens to discover supported symbols'), so alternative selection is only partially covered.
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.
list_swap_tokensswap_quoteBest-price cross-chain swap quotes across 70 chains (EVM + Solana). Holds no keys, never signs.
Swap quotes + unsigned txs on 8 EVM chains, plus Solana data: boards, candles, wallet PnL. No key.
Token swaps at the best net price on 9 EVM chains and Solana. No API key, non-custodial.
Swap, bridge and get gas on 6 EVM chains. Each plan states its outcome before you sign. No API key.
Add one secure layer between your agents and this server.
