Skip to main content
Glama

prepare_uniswap_swap

DestructiveIdempotent

Prepare a direct Uniswap V3 swap for same-chain ERC-20 and native token swaps, automatically selecting the best pool fee tier.

Instructions

Prepare a direct Uniswap V3 swap (bypasses LiFi aggregator). Use this ONLY when the user explicitly asks for Uniswap — otherwise default to prepare_swap which compares routes across venues. Same-chain only (Uniswap V3 is not a bridge). Auto-picks the best pool fee tier (100/500/3000/10000 bps) by quoting all four against QuoterV2 and choosing the one with the best price; pass feeTier to override. Supports ERC-20 <-> ERC-20, native-in (ETH -> ERC-20), and native-out (ERC-20 -> ETH). Both exact-in and exact-out. Returns an unsigned tx (with a reset+approve chain when the router needs allowance) that send_transaction can forward to Ledger Live. Single-hop only in v1 — multi-hop routes through an intermediate asset (e.g. via WETH) fall back to prepare_swap.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
walletYes
chainYes
fromTokenYes
toTokenYes
amountYesHuman-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 `amountSide: "to"` for exact-out. The tool resolves decimals on-chain.
amountSideNoWhich side of the swap `amount` refers to. "from" (default) = exact-in: spend exactly `amount` of fromToken, receive a variable output. "to" = exact-out: receive exactly `amount` of toToken, input sized to hit the target.
fromTokenDecimalsNoOptional decimals hint for fromToken if on-chain lookup fails. Native is 18.
toTokenDecimalsNoOptional decimals hint for toToken if on-chain lookup fails. Native is 18.
slippageBpsNoSlippage tolerance in basis points (50 = 0.5%). Default 50. Hard-capped at 500 (5%); > 100 requires `acknowledgeHighSlippage: true` to prevent MEV sandwiching.
acknowledgeHighSlippageNoOpt-in flag required when slippageBps > 100. Forces explicit acknowledgement of unusually-high slippage.
feeTierNoOptional fee-tier override (100 / 500 / 3000 / 10000 bps). When omitted, QuoterV2 is queried across all four tiers and the best-pricing pool is picked.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial behavioral context beyond annotations: auto-picks best fee tier, supports native and ERC-20, exact-in/out, returns unsigned tx with reset+approve chain, single-hop only, and fallback to prepare_swap for multi-hop. Annotations (destructiveHint, idempotentHint) are not contradicted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is well-structured and front-loaded with purpose and usage restriction. Each sentence adds value, though slightly lengthy. No fluff, but could be more compact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all essential aspects: usage restriction, supported chains, token types, exact-in/out, fee selection, slippage, return type (unsigned tx), allowance handling, and limitation (single-hop). Adequate despite no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already has good descriptions for most parameters (64% coverage). The description adds global operational context (e.g., fee tier auto-selection, human-readable amount, on-chain decimal resolution) that clarifies parameter behavior beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it prepares a direct Uniswap V3 swap, bypassing the LiFi aggregator, and distinguishes from sibling 'prepare_swap' which compares routes across venues. The verb 'prepare' and resource 'Uniswap V3 swap' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this ONLY when the user explicitly asks for Uniswap — otherwise default to prepare_swap which compares routes across venues.' Provides clear when-to-use, when-not, and names the alternative tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/szhygulin/vaultpilot-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server