Skip to main content
Glama

prepare_uniswap_v3_mint

DestructiveIdempotent

Build an unsigned transaction to mint a Uniswap V3 LP position with specified token pair, fee tier, tick range, and deposit amounts.

Instructions

Build an unsigned Uniswap V3 LP mint transaction — opens a new concentrated-liquidity position on the (tokenA, tokenB, feeTier) pool, bounded by [tickLower, tickUpper]. Up to two ERC-20 approvals are chained ahead of the mint() call (one per nonzero deposit side); USDT-style reset is handled automatically. The pool must already exist (initialized) — refuses with a clear error otherwise. Tick bounds MUST align to the fee tier's tickSpacing (100→1, 500→10, 3000→60, 10000→200); mis-aligned ticks are rejected rather than silently rounded. v1 limitation: only WETH (not native ETH) is supported as a pair side; wrap ETH first via prepare_native_send to the WETH contract. Slippage defaults to 50 bps (0.5%); soft cap at 100 bps requires acknowledgeHighSlippage: true. After signing the mint, the resulting LP NFT appears in get_lp_positions for the recipient address.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
walletYes
chainNoethereum
tokenAYesFirst token in the LP pair. Pass either order; the builder canonically sorts to (token0, token1) before submission. Native ETH is NOT supported in v1 — wrap to WETH first via prepare_native_send to the WETH contract.
tokenBYesSecond token in the LP pair. Must differ from tokenA.
feeTierYesPool fee in hundredths of a bip: 100 = 0.01%, 500 = 0.05%, 3000 = 0.3%, 10000 = 1%. Each fee tier is a separate pool; pick the one that matches the pair's volatility.
tickLowerYesLower tick of the position's price range. MUST align to the fee tier's tickSpacing (100→1, 500→10, 3000→60, 10000→200) — mis-aligned ticks are rejected. Use Uniswap UI or a tick-from-price helper to derive the value; passing arbitrary ints risks creating a position at a price the user did not intend.
tickUpperYesUpper tick. Must be > tickLower and aligned to tickSpacing.
amountADesiredYesHuman-readable decimal amount of tokenA to deposit. Example: "100.5" for 100.5 USDC. NOT raw wei. Pass "0" for a single-sided range deposit when the current price is outside the range and only the other token is needed.
amountBDesiredYesHuman-readable decimal amount of tokenB. Same shape as amountADesired.
slippageBpsNoSlippage tolerance in basis points (1 bp = 0.01%). Default 50 bps (0.5%). Hard ceiling 500 bps; soft cap 100 bps requires acknowledgeHighSlippage: true. Higher slippage masks bad fills and is a sandwich-bait misconfiguration.
acknowledgeHighSlippageNoRequired when slippageBps is in (100, 500]. Surface the trade-off to the user before proceeding — wide slippage on an LP mint locks the unfavourable amounts.
deadlineSecNoSeconds from now until the on-chain `deadline` parameter expires. Default 1200 (20 min).
recipientNoAddress to receive the minted LP NFT. Default: wallet (the depositor).
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?

The description adds substantial behavioral context beyond annotations: it discloses that up to two ERC-20 approvals are chained automatically, USDT-style reset is handled, the pool must exist (else error), misaligned ticks are rejected rather than silently rounded, and v1 limitation of no native ETH. It also mentions slippage behavior and post-mint visibility in get_lp_positions. Annotations indicate destructiveHint=true and idempotentHint=true, which align with the description.

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?

The description is dense but every sentence adds value. The main purpose is front-loaded in the first sentence. Subsequent sentences cover approvals, constraints, v1 limitations, slippage, and post-mint behavior. There is no filler or redundancy; each clause earns its place.

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?

Despite having no output schema and 14 parameters (8 required), the description is remarkably complete. It explains the transaction building process, pre-requisites (pool existence, tick alignment), parameter behavior, error cases, v1 limitations, slippage, and follow-up actions (NFT appears in get_lp_positions). It effectively equips an AI agent to select and invoke the tool correctly.

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?

With 86% schema description coverage, the description adds significant meaning beyond the schema: it explains human-readable amounts vs raw wei, single-sided range deposits, tick alignment to tickSpacing, slippage defaults and soft caps, and approval cap options (unlimited/exact/specific). This provides essential context that the schema alone does not fully convey.

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 uses specific verbs ('build', 'opens') and resource ('unsigned Uniswap V3 LP mint transaction') to clearly define the tool's purpose. It distinguishes from sibling tools like prepare_uniswap_v3_burn by focusing on minting a new concentrated-liquidity position, and it explicitly states the pool and tick bounds.

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

Usage Guidelines4/5

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

The description provides explicit when-to-use guidance for opening a new position, and when-not-to-use conditions: pool must exist, ticks must align to fee tier's tickSpacing, only WETH supported (not native ETH). It also mentions slippage defaults and the need for acknowledgeHighSlippage above 100 bps. However, it does not explicitly compare to sibling tools for existing positions (e.g., prepare_uniswap_v3_increase_liquidity), which would further clarify usage boundaries.

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