Skip to main content
Glama

prepare_curve_swap

DestructiveIdempotent

Build an unsigned Curve swap on Ethereum for stETH/ETH or stable_ng plain pools. Handles coin index resolution and automatic approval, with mandatory slippage protection.

Instructions

Build an unsigned Curve swap on Ethereum. Issue #615. Supports the canonical legacy stETH/ETH pool (0xDC24316b9AE028F1497c275EB9192a3Ea0f67022 — historically the tightest-spread venue for stETH↔ETH) and any plain pool registered with the stable_ng factory (covers crvUSD/USDC, USDe/USDC, etc.). Pass pool + fromToken + toToken; the tool resolves coin indices from the pool's coins array. Use fromToken: "native" for the ETH leg of the stETH/ETH pool (the only currently-supported pool whose coins(i) returns the ETH sentinel). Slippage gate REQUIRED: slippageBps (server reads get_dy and applies the cap) or minOut (explicit decimal-string uint256). The pool's exchange() accepts min_dy=0 silently — defaulting to that would let MEV extract the entire output. ERC-20 inputs chain an approval to the pool automatically. Rejected: meta pools (use exchange_underlying — different ABI), cryptoswap / tricrypto / older legacy stable pools (uint256 indices, use_eth flag — different selectors). For unsupported Curve pairs, fall back to prepare_swap (LiFi).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
walletYes0x EVM wallet address that will sign the tx.
poolYesCurve pool address. Must be the canonical legacy stETH/ETH pool (0xDC24316b9AE028F1497c275EB9192a3Ea0f67022) or a stable_ng factory plain pool. Meta pools, cryptoswap, tricrypto, and older legacy stable pools are rejected with a clear error.
fromTokenYesToken to spend. Pass `"native"` only for pools whose `coins(i)` returns the ETH sentinel (0xeeee...eeee) at some index — currently the legacy stETH/ETH pool. For ERC-20 inputs the tool chains an approval to the pool automatically.
toTokenYesToken to receive. Same rules as `fromToken`. Must differ from `fromToken` and both must appear in the pool's `coins` array.
amountYesHuman-readable decimal input amount in the from-token (e.g. "1.5"). Decimals are read from the from-token contract; native = 18.
slippageBpsNoSlippage tolerance in basis points (50 = 0.5%). When set, `min_dy = get_dy(i,j,dx) * (1 - slippageBps/10000)`. Either `slippageBps` or `minOut` is required — the pool's exchange() accepts `min_dy=0` silently and defaulting to that would let MEV extract the entire output. Capped at 5% (500 bps).
minOutNoExplicit minimum output in the to-token's wei (decimal-string uint256). Takes precedence over `slippageBps` when both are provided.
acknowledgeHighSlippageNoRequired when `slippageBps > 100` (1%). Same gate as `prepare_swap` — sandwich-MEV bots target wide-slippage txs.
acknowledgeNonAllowlistedSpenderNoAFFIRMATIVE GATE — required whenever `fromToken` is an ERC-20 (the approve leg targets the Curve pool, which is NOT in the global protocol approve-allowlist: Aave Pool, Compound Comet, Morpho Blue, Lido Queue, EigenLayer, Uniswap NPM, Uniswap SwapRouter02, LiFi Diamond). The allowlist is a security recommendation, not a hard requirement: it limits approvals to a small set of well-known spenders to keep prompt-injection drains from sliding through. Setting this flag is the user's affirmative ack that they understand the approval target sits outside that curated set — the on-device clear-sign of `approve(<curve-pool>, <amount>)` and the prepare-receipt warning advisory are the verification anchors. Do NOT default this to true silently; surface the trade-off to the user first. Ignored when `fromToken: "native"` (no approval; native ETH is sent as msg.value).
approvalCapNoCap on the ERC-20 approval preceding this action. Omit for "unlimited" (standard DeFi UX — fewer follow-up approvals). Pass "exact" to approve only what this action pulls. Pass a decimal string (e.g. "500") for a specific ceiling in the asset's human units; must be ≥ the action amount, otherwise the transaction would revert.
Behavior5/5

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

Discloses automatic approval chaining for ERC-20, coin index resolution from pool's coins array, and the security gate acknowledgeNonAllowlistedSpender because Curve pool is not in the global allowlist. Annotations already mark destructive and idempotent; description adds rich behavioral context without contradiction.

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

Conciseness5/5

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

Every sentence adds value. Front-loaded with purpose, then specifics on pools, parameters, slippage, approvals, exclusions, and fallback. Efficient and clear despite length.

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 relevant aspects: supported pools, coin index logic, slippage safety, approval gates, fallback, and allowlist rationale. For a complex 10-parameter tool with no output schema, it is remarkably complete.

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

Parameters5/5

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

Schema coverage is 100%, but the description significantly enriches parameters: explains slippageBps calculation, minOut precedence, the reason for acknowledgeNonAllowlistedSpender, and approvalCap options. Exceeds baseline.

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?

The description clearly states 'Build an unsigned Curve swap on Ethereum' and specifies supported pools (canonical stETH/ETH and stable_ng factory plain pools). It also distinguishes from sibling tools like prepare_swap by noting fallback for unsupported Curve pairs.

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?

Provides explicit when-to-use: for supported Curve pools; when-not-to-use: for meta pools, cryptoswap, tricrypto, older legacy pools; and alternatives: fall back to prepare_swap (LiFi). Also details required slippage gate with rationale about MEV.

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/recon-crypto-mcp'

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