Skip to main content
Glama

prepare_uniswap_v3_rebalance

DestructiveIdempotent

Build an unsigned transaction to rebalance a Uniswap V3 LP position to a new tick range in a single multicall, handling slippage for both closing and re-deposit phases.

Instructions

Build an unsigned Uniswap V3 LP rebalance transaction — moves a position from its current tick range to a new one in a single multicall. Composes (in order): decreaseLiquidity(100%) + collect + (optional) burn + mint(new range). The position's (token0, token1, fee) carry over; only the tick range changes. Slippage is independently applied to the close + re-deposit phases — the effective tolerance against the spot price is roughly 2× the input bps. The description block calls this out explicitly. v1 amount-source: the new mint's amount0Desired/amount1Desired are estimated from the position's expected burn amounts at current price; on-chain the actual mint pulls bounded by what was actually collected, with surplus refunded to the wallet by the NPM. Up to two ERC-20 approvals are chained ahead of the multicall (the mint phase still needs them — collect routes the tokens back to the wallet, then mint pulls them again via transferFrom). Hard-refuses on owner mismatch, mis-aligned new ticks, identical new range, or zero-liquidity position.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
walletYes
chainNoethereum
tokenIdYesERC-721 tokenId of the LP NFT to rebalance. Must be owned by `wallet`. Its (token0, token1, fee) are reused for the new mint — only the tick range changes.
newTickLowerYesLower tick of the NEW range. Must align to the position's fee-tier tickSpacing (100→1, 500→10, 3000→60, 10000→200) and be < newTickUpper.
newTickUpperYes
burnOldNoWhether to also burn the old NFT in the same multicall. Default true — the old position has zero liquidity after the close phase and a stub NFT serves no purpose. Set to false to keep the old tokenId alive (e.g. for off-chain bookkeeping).
slippageBpsNoSlippage tolerance in bps applied INDEPENDENTLY to the close phase (decreaseLiquidity floor) and the re-deposit phase (mint floor). The effective tolerance against the spot price is roughly 2× this value. Default 50 bps; soft cap 100 bps requires acknowledgeHighSlippage.
acknowledgeHighSlippageNo
deadlineSecNo
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 goes well beyond annotations, detailing the exact multicall composition (decreaseLiquidity, collect, optional burn, mint), independent slippage, chained ERC-20 approvals, and hard refusals. Annotations only indicate destructive and idempotent, but the description provides rich behavioral context.

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?

The description is detailed and well-structured with bold emphasis, but it is somewhat long. It front-loads the main action and uses concise phrasing, though some sections (e.g., slippage, approvals) could be tightened further. Still, it is efficient for the complexity.

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?

Given 10 parameters, no output schema, and the complexity of a rebalance tool, the description is nearly complete. It covers the composed actions, slippage behavior, approval chaining, hard refusals, and parameter details. No major gaps are apparent.

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 50%, but the description adds meaning for key parameters like tokenId (owned by wallet, token0/token1/fee reused), newTickLower (must align to tickSpacing), burnOld (default true explanation), slippageBps (applied independently, effective 2x, default 50, cap 500 with acknowledgeHighSlippage), and approvalCap (options). It compensates well for gaps.

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 it builds an unsigned Uniswap V3 LP rebalance transaction, moving a position from its current tick range to a new one in a single multicall. It distinguishes from siblings that are individual actions like prepare_uniswap_v3_mint, etc., by specifying it composes multiple steps.

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 explains when to use it: to rebalance a Uniswap V3 LP position, and lists hard refusals (owner mismatch, misaligned ticks, identical range, zero liquidity). It implies alternatives like individual mint/burn tools but doesn't explicitly state when not to use this tool versus others.

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