Skip to main content
Glama

prepare_curve_add_liquidity

DestructiveIdempotent

Create an unsigned Curve add_liquidity transaction for stable_ng plain pools on Ethereum, bundling ERC-20 approvals. Requires deposit amounts and slippage tolerance.

Instructions

Build an unsigned Curve add_liquidity transaction for a stable_ng plain pool on Ethereum. Bundles ERC-20 approvals (one per non-zero deposit slot) before the action call via chainApproval. Pass amounts as a decimal-string array matching the pool's N_COINS (use '0' for slots you're not depositing into — single-coin deposit). Slippage gate is REQUIRED: pass either minLpOut (explicit decimal-string uint256) OR slippageBps (server computes via calc_token_amount * (1 - bps/10000)). v0.1 scope: stable_ng plain pools only — meta pools rejected. Use get_curve_positions to discover valid pool addresses + their coin order before calling this.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
walletYes0x EVM wallet address that will sign the tx.
poolYesPool address (== LP token address on stable_ng). Must be a stable_ng plain pool — meta pools rejected with a clear error in v0.1; use `get_curve_positions` to discover valid pools the wallet has access to.
amountsYesPer-coin deposit amounts as decimal-string-encoded uint256, in the order returned by `get_curve_positions(...).coins`. Length must match the pool's N_COINS. Pass '0' for slots you're not depositing into (single-coin deposit).
minLpOutNoExplicit minimum LP tokens to receive (decimal-string uint256). Passes through to the pool's `add_liquidity(amounts, min_mint_amount)`. Either `minLpOut` or `slippageBps` is required.
slippageBpsNoServer-side slippage allowance in basis points (e.g. 50 = 0.5%). When set, `minLpOut = calc_token_amount * (1 - slippageBps / 10000)`. Capped at 10% (1000 bps) to prevent accidental wide gates. Either `minLpOut` or `slippageBps` is required.
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 bundling of ERC-20 approvals, slippage computation via server, and rejection of meta pools. Consistent with annotations; no contradictions.

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 is informative and purposeful, front-loaded with primary action, then sequentially covers details without redundancy.

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 critical aspects: purpose, parameter usage, scope constraints, prerequisites, and behavioral nuances. Adequate given no output schema and 6 parameters.

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?

Adds substantial detail beyond schema: amounts format as decimal strings with '0' for empty slots, slippage gate requirement with two forms, approvalCap behavior (unlimited/exact/custom min), and the prerequisite get_curve_positions.

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 builds an unsigned Curve add_liquidity transaction for stable_ng plain pools, with specific verb and resource, and distinguishes from sibling tools like prepare_curve_swap.

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 states scope limitations (only stable_ng plain pools, meta pools rejected), requires slippage gate with two options, recommends using get_curve_positions for discovery, and explains approvalCap options.

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