Skip to main content
Glama

prepare_uniswap_v3_mint

DestructiveIdempotent

Build an unsigned Uniswap V3 LP mint transaction to open a concentrated liquidity position on an existing pool, with chained token approvals and slippage limits.

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?

Adds behavioral context beyond annotations: pool existence check, rejection of mis-aligned ticks, automatic approval chaining, slippage behavior, and v1 limitation. No contradiction with annotations (destructiveHint: true, idempotentHint: true are consistent with transaction building).

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?

Well-structured with front-loaded purpose, but slightly verbose with multiple clauses. Every sentence is informative, but some details (e.g., tick spacing mapping) could be streamlined. Still earns a high score for clarity.

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 major aspects: operation, prerequisites, constraints, limitations, defaults, and post-transaction visibility (LP NFT in get_lp_positions). No output schema, but description explains what the result is (unsigned transaction, chained approvals). Sufficient for a complex DeFi tool.

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 still adds value: explains tick alignment rationale, amount format (human-readable), slippage caps, approvalCap options (unlimited, exact, specific ceiling). Clarifies token ordering and pool fee tier selection.

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 verb+resource: 'Build an unsigned Uniswap V3 LP mint transaction — opens a new concentrated-liquidity position'. It clearly distinguishes from sibling tools like prepare_uniswap_v3_burn, prepare_uniswap_v3_collect, etc., by detailing the mint action and constraints.

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 when to use (pool must exist, tick alignment, WETH only) and when not to (native ETH unsupported, alternative wrapping via prepare_native_send). Also covers slippage defaults and high-slippage acknowledgment requirement.

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