prepare_swap
Prepare an unsigned swap or bridge transaction via LiFi aggregator. Same-chain swaps use the best DEX route; cross-chain swaps use a bridge + DEX combo. Default is exact-in (amount = fromToken); set amountSide: "to" for exact-out (amount = target toToken output, e.g. "I want 100 USDC out"). Sourc...
This record as markdown: /tools/io-github-szhygulin-vaultpilot-mcp/prepare-swap.md
What prepare_swap does on VaultPilot MCP
AI agents invoke prepare_swap to trigger actions in VaultPilot MCP. What it does depends on the arguments the agent supplies, and its effects often reach beyond the immediate call: builds kicked off, notifications sent, workflows started.
| Parameter | Type | Required | Description |
|---|---|---|---|
order | string | — | Route ranking criterion. RECOMMENDED (default) — LiFi's mix of price + safety. CHEAPEST — pick the route with the highest output amount; use this for "best rate |
amount | string | Yes | Human-readable decimal amount, NOT raw wei/base units. Example: "1.5" for 1.5 USDC, "0.01" for 0.01 ETH. Interpreted as fromToken input by default; set `amountS |
wallet | string | Yes | |
bridges | array | — | Restrict cross-chain routing to a specific set of bridge protocols. Common values: "across", "stargate", "hop", "cbridge", "amarok", "polygon", "arbitrum-bridge |
toChain | string | Yes | |
toToken | object | Yes | |
exchanges | array | — | Restrict LiFi routing to a specific set of DEX/exchange aggregators. Common values: "1inch", "sushiswap", "uniswap", "paraswap", "0x", "kyberswap", "odos", "ope |
fromChain | string | Yes | |
fromToken | object | Yes | |
toAddress | string | — | Destination wallet. OMIT for same-chain-type swaps (defaults to the source wallet — LiFi behavior). REQUIRED when `toChain` is `"solana"` or `"tron"` because th |
amountSide | string | — | Which side of the swap `amount` refers to. "from" (default) = exact-in: you spend exactly `amount` of fromToken and receive a variable output. "to" = exact-out: |
slippageBps | integer | — | Slippage tolerance in basis points (50 = 0.5%, 100 = 1%). Default ~50. Hard-capped at 500 (5%) — anything higher is almost always a sandwich-bait misconfigurati |
Parameters from the server's own tool schema.
Why prepare_swap is rated High
This tool prepares and routes a swap/bridge transaction across chains. While labeled 'prepare' (suggesting it may not submit), it constructs a real financial transaction (token swap or cross-chain bridge) that, once signed, transfers crypto assets. In a self-custodial DeFi context with Ledger signing, this is a critical step in an asset-moving workflow.
From the tool's definition Prepare an unsigned swap or bridge transaction via LiFi aggregator. Same-chain swaps use the best DEX route; cross-chain swaps use a bridge + DEX combo.
Risk signalsHigh parameter count (17 properties) · Bulk/mass operation — affects multiple targets
Attacks that exploit this kind of access
The rule that runs prepare_swap safely
PolicyLayer is an MCP gateway: it sits between your AI agents and VaultPilot MCP, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For prepare_swap, this is the rule to start with:
prepare_swap stays usable, but rate-capped: a runaway agent can't fire it dozens of times a minute. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect VaultPilot MCP, apply this rule, and every prepare_swap call is checked against it from then on.
Questions about prepare_swap
Prepare an unsigned swap or bridge transaction via LiFi aggregator. Same-chain swaps use the best DEX route; cross-chain swaps use a bridge + DEX combo. Default is exact-in (amount = fromToken); set amountSide: "to" for exact-out (amount = target toToken output, e.g. "I want 100 USDC out"). Source chain is always EVM. Destination can be any EVM chain, Solana, or TRON. For non-EVM destinations pass toChain: "solana" / "tron" + an explicit toAddress in the destination chain's format; the user signs an EVM tx and the bridge protocol delivers tokens to the destination after confirmation. The destination-side decimals cross-check is dropped for non-EVM destinations (we can't read SPL/TRC-20 via EVM RPC); LiFi's reported decimals are the source of truth there. Exact-out is not supported for cross-chain-to-non-EVM. For Solana-source swaps and bridges use prepare_solana_lifi_swap. TRON-source LiFi is not yet wired. PROTOCOL ROUTING (issue #411): without exchanges / bridges, LiFi picks the best-output route across all aggregators. When the user explicitly names a DEX ("swap on 1inch", "use Sushi"), pass exchanges: ["1inch"] (or the named protocol) — without the filter LiFi may silently route via a different DEX. If no route satisfies the filter the call errors with a clear message; the agent can offer to retry without the filter. The unsigned tx's description includes "via <tool>" and notes whether the resolved tool matched the filter. DECODING DEFENSE: every cross-chain bridge calldata is parsed into its BridgeData tuple and the encoded destinationChainId + receiver are cross-checked against what the user requested — refuses on mismatch. Catches a compromised MCP that returns calldata routing to a different chain or recipient than the prepare receipt advertises. INTERMEDIATE-CHAIN BRIDGES: NEAR Intents (notably for ETH→TRON USDT routes) settles on NEAR and releases on the final chain via an off-chain relayer, so its on-chain destinationChainId is NEAR's pseudo-id (1885080386571452) rather than the user's requested chain. The defense allows this ONLY for an explicit hardcoded (bridge name, intermediate chain ID) pair held as a source-code constant — not loaded from env / config / LiFi response — so a compromised aggregator can't claim arbitrary chains as 'intermediate'. Receiver-side checks (non-EVM sentinel, etc.) still apply unchanged. The returned tx can be sent via send_transaction. It is categorised as a Execute tool in the VaultPilot MCP MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
prepare_swap accepts 12 parameters: order, amount, wallet, bridges, toChain, toToken, exchanges, fromChain, fromToken, toAddress, amountSide, slippageBps. Required: amount, wallet, toChain, toToken, fromChain, fromToken. The full parameter table on this page comes from the server's own tool schema.
Register the VaultPilot MCP server in PolicyLayer and add a rule for prepare_swap: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches VaultPilot MCP. Nothing to install.
prepare_swap is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the prepare_swap rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for prepare_swap. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
prepare_swap is provided by the VaultPilot MCP server (vaultpilot-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on VaultPilot, and thousands of servers like it.
Across the catalogue