SwapWizard
Server Details
Non-custodial DeFi for AI agents: swaps, concentrated liquidity (V3/V4) zaps + ranges, 5 EVM chains
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 11 of 11 tools scored.
Each tool has a clearly distinct purpose: health check, setup guide, chain/dex list, pool discovery, pool analysis, swap quoting (with per-use-case variant), LP position listing, and single-transaction LP entry/exit. No significant overlap.
All tool names follow a consistent verb_noun pattern in snake_case (analyze_pool, get_swap_quote, list_user_lp_positions, etc.). Even 'zap_into_lp_position' and 'zap_out_of_lp_position' maintain the pattern with verbs 'zap_into' and 'zap_out_of'.
11 tools is well-scoped for a DeFi liquidity management server covering health, discovery, quoting, and LP operations. Each tool earns its place without redundancy.
Covers core workflows: pool discovery, analysis, swap quotes, LP position management, and single-transaction zap in/out. Missing is a direct token approval tool, but instructions for approvals are embedded in relevant tools. Minor gap but highly functional.
Available Tools
11 toolsanalyze_poolAInspect
Maps to GET /pools/analyze/:id. Returns real-time momentum data for a specific pool from GeckoTerminal: multi-timeframe volume (5m, 15m, 30m, 1h, 6h), price changes (5m–24h), buy/sell transaction counts, unique traders (24h), and reserve in USD. Data is cached for 10 minutes; stale entries are refreshed on-demand. Use the numeric id field returned by search_liquidity_pools.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Pool numeric ID (from the id field in search_liquidity_pools response) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses caching behavior (10-minute TTL, on-demand refresh) and output fields, giving agents full behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. First sentence maps endpoint and purpose, second adds caching and input source. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema or annotations, the description covers endpoint, input source, output data, and caching behavior, making it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema description already specifies the id's origin. The tool description adds only minor redundancy, so it meets baseline but does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool maps to a specific endpoint and returns real-time momentum data with enumerated fields. It distinguishes from sibling tool search_liquidity_pools by specifying that the id comes from that tool's response.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly directs agents to use the numeric id from search_liquidity_pools, providing clear context on when to invoke this tool. Lacks explicit exclusions but sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_api_healthAInspect
Maps to GET /health. Returns service availability. Use to confirm the API is responsive before attempting operations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the tool returns service availability and is a read-only health check. It could be slightly more specific about what 'available' entails, but overall sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Efficiently conveys purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless health check with a simple boolean-like return, the description fully covers what is needed. No output schema is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. The description adds nothing beyond schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks API health and maps to GET /health, which distinguishes it from sibling tools focused on liquidity pools, quotes, and user positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this tool to confirm API responsiveness before operations, providing clear context and when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_clean_quoteAInspect
Maps to POST /quote with excludePositions=true. Shortcut to get_swap_quote that prices the swap as if the caller's own LP position were not in the pool, for concentrated-liquidity positions in the active tick range. Use when an agent holds a significant position in the pool it is about to trade against (rebalancing, exit, treasury sizing) and needs a quote unaffected by its own liquidity. Returns the same router/callData/value execution fields as get_swap_quote, and likewise supports an optional affiliateCode (registered affiliate wallet address) forwarded to the API. EXECUTION FLOW: same as get_swap_quote — approve (wait for confirmation), fresh quote, then send tx to the router contract (requires private key or wallet signer). ⚠️ PRICE IMPACT: The response includes a priceImpact field. Agents MUST present this value to the user and request explicit confirmation before executing. ⚠️ ZERO OUTPUT: If the swap amount is too small relative to the token pair price ratio, the API returns HTTP 400 with "swap amount too small: output rounds to zero for this pair". Increase the amount or use a different pair.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | Quote direction | |
| owner | Yes | Wallet address whose LP positions will be excluded from pool state during quoting | |
| amount | Yes | Amount as stringified uint256 in token decimals | |
| rpcUrl | No | Custom RPC endpoint URL for position discovery. | |
| chainId | Yes | EVM chain ID (e.g. 56 for BSC) | |
| tokenIn | Yes | Input token address (0x0000...0000 for native coin) | |
| tokenOut | Yes | Output token address | |
| slippageBps | No | Slippage tolerance in basis points (default: 100 = 1%) | |
| affiliateCode | No | Optional affiliate wallet address registered on-chain with SwapWizard — forwarded to the API so the affiliate fee for this operation is paid to that address. Omit if you have no affiliate. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It details the execution flow (approve, wait for confirmation, fresh quote, send tx), requires private key/wallet signer, warns about priceImpact requiring user confirmation, and describes the zero output error case. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the mapping, then purpose, execution flow, and warnings. Although somewhat lengthy, every sentence is informative and earns its place. Minor conciseness improvement possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no output schema, the description covers execution flow, warnings, and error cases. It references get_swap_quote for return fields, which is helpful but leaves some completeness gap. Overall adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 9 parameters. The description adds value by clarifying that 'owner' is the wallet whose LP positions are excluded and that 'affiliateCode' is forwarded to the API. While schema already describes most parameters, these additions justify a score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool maps to POST /quote with excludePositions=true and is a shortcut to get_swap_quote that excludes the caller's own LP position. It specifies use cases (rebalancing, exit, treasury sizing) and distinguishes it from the sibling tool get_swap_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: when the agent holds a significant position in the pool it is about to trade against. It also mentions that it returns the same fields as get_swap_quote and supports an optional affiliateCode. Although it does not explicitly state when not to use, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_setup_guideAInspect
Returns the complete setup and usage guide for SwapWizard. Call this FIRST before using any other tool. Covers: required configuration (API key, Alchemy RPC URL, private key), how to use poolId correctly, step-by-step operational flows for swap/zap in/zap out/analyze, transaction execution details, and approval rules.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the tool returns a guide and covers specific topics. However, it does not explicitly state that the operation is read-only or idempotent, which would be helpful but not critical for a zero-parameter retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences: first states purpose, second gives usage instruction, third enumerates contents. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and a simple read-only guide retrieval, the description sufficiently explains what the tool does, when to use it, and what it covers. No additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so no additional parameter documentation is needed. The baseline for 0 params is 4, and the description adds no param info, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the complete setup and usage guide for SwapWizard, with a specific verb ('Returns') and resource ('setup and usage guide'). It distinguishes from sibling tools by explicitly instructing to call this FIRST before any other tool, making its unique role clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use: 'Call this FIRST before using any other tool.' This is a clear prerequisite instruction. It also lists covered topics, further guiding usage. No ambiguity about when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_supported_chainsAInspect
Maps to GET /chains. Lists supported EVM chains with chain IDs and native gas tokens: Ethereum, Arbitrum, Base, Polygon, BNB Chain.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It notes the HTTP mapping and lists chains, but does not explicitly state that it is read-only or idempotent. However, the operation is inherently safe, and the description is accurate. Minimal behavioral context added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences with no wasted words. It front-loads the HTTP mapping and provides specific examples. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema, no annotations), the description is mostly complete. It tells the agent what it does and gives examples of return content. Could be slightly more explicit about the output format but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description cannot add meaning beyond the schema. Baseline for 0 parameters is 4. Description does not need to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool maps to a specific endpoint and lists supported EVM chains with chain IDs and native gas tokens, naming specific examples. This distinguishes it from sibling tools like get_supported_dexes or get_swap_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving supported chains. It does not explicitly state when to use or when not to, but the simplicity of the tool (no parameters) makes the use case self-evident. Lacks explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_supported_dexesAInspect
Returns the AMMs / DEX sources SwapWizard routes across per chain. Each DEX includes its display name and slug (e.g. "uniswap-v3") — use the slug as the 'project' filter in search_liquidity_pools to filter pools by protocol.
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | No | EVM chain ID to filter results. If omitted, returns protocols for all supported chains. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses it returns read-only data with no side effects. It clearly describes output and behavior per chain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words, front-loaded with purpose and efficient additional details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return structure (name and slug) and usage, sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers chainId with full description; the description adds minimal extra meaning beyond 'per chain'. Baseline 3 due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns AMMs/DEX sources per chain with display name and slug, distinguishing it from sibling tools like get_supported_chains and search_liquidity_pools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on using the slug in search_liquidity_pools, but does not explicitly state when to use this tool vs alternatives. The context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_swap_quoteAInspect
Maps to POST /quote. Returns the best swap quote across all integrated DEX protocols, with router, callData, value, price impact, route summary, and gas estimate in one response. Surplus and positive slippage are returned to the user in the same transaction. Supports an optional affiliateCode (registered affiliate wallet address) forwarded to the API so the affiliate fee is paid on-chain to that address. Supports an excludePositions parameter that prices the swap excluding the caller's own LP position from pool state. Returns signable data only; never signs or broadcasts. EXECUTION FLOW: (1) If the input token is non-native, send an ERC-20 approve to the router and WAIT for on-chain confirmation. (2) Call this tool again for a fresh quote (quotes expire). (3) Send the tx to the router contract: to=router, data=callData, value=value. This requires a private key or wallet signer. ⚠️ PRICE IMPACT: The response includes a priceImpact field. Agents MUST present this value to the user and request explicit confirmation before executing. High price impact means the user will receive significantly less value than expected. ⚠️ ZERO OUTPUT: If the swap amount is too small relative to the token pair price ratio, the API returns HTTP 400 with "swap amount too small: output rounds to zero for this pair". Increase the amount or use a different pair.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | Quote direction | |
| amount | Yes | Amount as stringified uint256 in token decimals | |
| chainId | Yes | EVM chain ID (e.g. 56 for BSC) | |
| tokenIn | Yes | Input token address (0x0000...0000 for native coin) | |
| tokenOut | Yes | Output token address | |
| slippageBps | No | Slippage tolerance in basis points (default: 100 = 1%) | |
| affiliateCode | No | Optional affiliate wallet address registered on-chain with SwapWizard — forwarded to the API so the affiliate fee for this operation is paid to that address. Omit if you have no affiliate. | |
| excludePositions | No | Positions to subtract from pool state during simulation — for a clean quote that excludes self-impact. Get these from list_user_lp_positions. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly discloses that the tool only returns signable data (never signs/broadcasts), requires on-chain approval for non-native tokens, quotes expire, and mandates presenting price impact to users. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds value. The description is structured with core purpose, return fields, important notes, execution flow, and warnings. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and complex execution, the description covers all necessary context: error handling, price impact display, affiliate fee mechanism, and prerequisite approval steps. Complete enough for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaning beyond schema by explaining affiliateCode as an affiliate wallet address and excludePositions as excluding self-impact from pool state. This enhances understanding for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool maps to POST /quote and returns the best swap quote with router, callData, value, price impact, route summary, and gas estimate. It distinguishes itself from siblings like get_clean_quote by specifying it aggregates across all integrated DEX protocols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a detailed execution flow (approve, re-call for fresh quote, send tx), warnings about price impact, and zero output error handling. Lacks explicit comparison to sibling tools but gives sufficient context for proper use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_user_lp_positionsAInspect
Maps to GET /positions. Reads all LP positions a wallet holds on a given chain by calling the SwapWizard API, which discovers positions across all supported protocols: Uniswap V2/V3/V4, Aerodrome, Thena, SushiSwap, PancakeSwap, Algebra, Balancer, Curve, and all Solidly forks. Each position includes positionId, nftManager, dexName, liquidityKind, token addresses, amounts, fees, in-range status, APR, and USD values. EXIT SIGNAL: each position also carries momentumSignal for its pool — "exit" means the pool's volume is dying or LPs are leaving (consider zapping out), "watch"/"entry" mean momentum is still alive. When momentumSignal is ABSENT, the pool has dropped out of the momentum ranking (momentum exhausted) — also a reason to review and likely exit the position. momentumScore is the composite strength. Use this to drive exit decisions, mirroring the entry signal from search_liquidity_pools. The API uses Alchemy's NFT APIs for optimal position discovery — pass an Alchemy RPC URL via rpcUrl for fastest results. Without an Alchemy key, the API falls back to on-chain scanning which may be slower and newly created positions may take longer to appear. IMPORTANT: Always call this BEFORE zap_out_of_lp_position — pass the returned positionId, nftManager, dexName, and liquidityKind directly to zap_out_of_lp_position.
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | Wallet address to query positions for | |
| rpcUrl | No | Custom RPC endpoint URL. If the URL is from Alchemy, the API auto-extracts the key for accelerated NFT-based position discovery. | |
| chainId | Yes | EVM chain ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: it is a read operation, explains fallback mechanism, performance implications, and the significance of momentumSignal field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loaded with core purpose, and every sentence provides valuable information about features, usage, and integration with sibling tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers protocols, fields, exit signals, and usage guidance thoroughly. Lacks pagination details but given the nature of listing positions for a wallet, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds context beyond schema, especially for rpcUrl (Alchemy usage) and fallback behavior, but does not elaborate on chainId or owner beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads LP positions for a wallet on a chain, lists supported protocols and fields, and distinguishes itself from sibling tools like search_liquidity_pools and zap_out_of_lp_position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it should be called before zap_out_of_lp_position and mirrors entry signals from search_liquidity_pools. Also explains when to use rpcUrl for optimal performance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_liquidity_poolsAInspect
Maps to GET /pools. Discovers liquidity pools across supported AMMs and chains, returning id, poolId, symbol, underlyingTokens (token addresses), fee tier, protocol, dexKind, APY, apyBase (fee-only APY excluding reward emissions), TVL (USD), 24h/7d volume (USD), stablecoin flags, and hooksAddress (custom hook contract for Uniswap V4 / PancakeSwap Infinity pools; null when the pool has no hook — hooks can add custom fees or transfer restrictions). KEY PARAMETERS: Use trending: true to get only pools currently trending, optionally with timeframe ("5m", "1h", "6h", "24h") to select the ranking window — default is 5m. Trending results include feeAprEstimate: fee APR (%) annualized from the selected timeframe's volume window over the pool reserve (null outside trending mode or when the fee tier is unknown). NOTE: feeAprEstimate extrapolates a short window to a year — for short timeframes on hot pools it can be extreme and short-lived; the apy field is the stable 24h-based metric.
MOMENTUM SIGNAL (1h/6h/24h windows, powered by on-chain DEX trade data): each trending pool carries momentumSignal — "entry" (volume accelerating with healthy LP flow — a pool worth entering), "watch" (in the ranking but not yet actionable), or "exit" (dying volume or LPs leaving). Supporting fields: momentumScore (composite acceleration x size x flow quality), momentumRatioH1/H6/H24 (volume vs the previous equal window), momentumTakersH6 (unique traders 6h), lpMintsH6/lpBurnsH6 and lpNetFlowH6 (inflow/outflow/flat — are LPs adding or pulling liquidity). The 5m window carries the signal as HOURLY CONTEXT (last hourly cycle, not the last 5 minutes), since 5m is real-time GeckoTerminal data. Each pool also carries suggestedRangePct: a suggested concentrated-liquidity range (± percent) balancing fee density against time-in-range — ~0.5% for stable pairs, tens of percent for volatile/memecoin pairs — pass it to zap_into_lp_position. To ENTER the hottest profitable pool: trending: true, timeframe: "6h", signal: "entry", sortBy: "signal", sortOrder: "desc" returns entry-signal pools ranked by APR. (Use timeframe "6h" for sustained traction / LP-yield strategies, "1h" for faster reaction.) To check whether to EXIT, read momentumSignal on list_user_lp_positions instead.
Use hookless: true to exclude pools with a custom hook contract. Use sortBy ("apy", "tvl", "volume1d", "volume7d", "signal") with sortOrder to control ranking — default is tvl desc. Use topPerVenue to limit to top N pools per DEX by APY. Supports filtering by protocol/DEX, tokens, pool type, stablecoin status, and free-text search, with pagination. Required upstream step before zap_into_lp_position. IMPORTANT: The response contains two ID fields — poolId (string) must be passed AS-IS to zap_into_lp_position and zap_out_of_lp_position (do NOT construct or modify it), and id (number) is used only for analyze_pool.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, 0-based (default: 0) | |
| search | No | Search by symbol or project name | |
| signal | No | Filter by momentum signal. Comma-separated list allowed (e.g. 'entry' or 'entry,watch'). Only effective with trending=true. Combine with sortBy=signal&sortOrder=desc to get entry pools ranked by APR. | |
| sortBy | No | Sort field (default: tvl). 'signal' (trending only) groups pools by momentum signal entry→watch→exit (sortOrder=asc reverses) and within each group by APR descending — i.e. the entry pools with the highest APR first. | |
| tokens | No | Comma-separated token addresses to filter pools by | |
| chainId | Yes | EVM chain ID (e.g. 56 for BSC, 1 for Ethereum) | |
| dexKind | No | Filter by DEX kind (e.g. UNIV3_SR02) | |
| project | No | Filter by protocol/DEX name (e.g. uniswap-v3, pancakeswap-v3, aerodrome-v2) | |
| hookless | No | If true, exclude pools with a custom hook contract (Uniswap V4 / PancakeSwap Infinity). Hooks can add custom fees or transfer restrictions. | |
| pageSize | No | Results per page, max 200 (default: 50) | |
| poolType | No | Filter by pool type | |
| trending | No | If true, return only currently trending pools (with momentumSignal and suggestedRangePct on each result) | |
| sortOrder | No | Sort direction (default: desc) | |
| timeframe | No | Trending ranking window (default: 5m). Only applies with trending=true. Sent to the API as trendingDuration; also selects the volume window for feeAprEstimate. Use 6h for sustained LP-yield traction, 1h for faster reaction; 5m is real-time GeckoTerminal with the signal as hourly context. | |
| stableOnly | No | Show only stablecoin pairs | |
| topPerVenue | No | Limit to top N pools per venue by APY | |
| semiStableOnly | No | Show only pools with exactly one stablecoin |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It fully discloses the endpoint, return fields (id, poolId, symbol, underlyingTokens, fee tier, protocol, dexKind, APY, apyBase, TVL, volume, stablecoin flags, hooksAddress), and behavioral nuances: feeAprEstimate warning about extrapolation being extreme, momentumSignal behavior (entry/watch/exit), handling of 5m window signal as hourly context, and the distinction between poolId and id fields for downstream use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long due to the tool's complexity (17 parameters, many output fields), but it is well-structured with clear topic sections (general, trending, momentum signal, usage examples, parameters). Every sentence adds value, and the most critical information (endpoint, key fields, typical usage) is front-loaded. Minor room for improvement in breaking into shorter paragraphs, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (17 parameters, no output schema, many return fields and behavioral details), the description covers all necessary aspects: input parameters with strategic usage, return field explanations, warnings, relationships with sibling tools (required before zap_into_lp_position, exit check via list_user_lp_positions), and specific query examples. It is fully self-contained and leaves no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds significant contextual usage guidance beyond schema descriptions, such as explaining the effect of sortBy='signal' (groups by momentum signal then APR), the interaction of trending, timeframe, and signal, and how to combine parameters for specific strategies. This adds meaning that helps the agent construct correct parameter combinations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it maps to GET /pools and discovers liquidity pools across AMMs and chains. It distinguishes itself from siblings by explicitly labeling itself as a required upstream step before zap_into_lp_position, and contrasts with analyze_pool (analysis of a single pool) and list_user_lp_positions (checking exit signals).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive when-to-use guidance, including examples like using trending:true with specific timeframe and signal parameters to find entry pools, and advising to use list_user_lp_positions instead for checking exit signals. It also explains when to use different timeframes (6h for sustained traction, 1h for faster reaction). This explicitly guides the agent on usage vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
zap_into_lp_positionAInspect
Maps to POST /addliquidity/quote. Builds a single-transaction zap to enter an LP position from ANY input token — the deposit token does NOT have to be one of the pool's underlying tokens. SwapWizard handles all intermediate swaps, the LP mint, and price-range setup in a single transaction. FULL CONCENTRATED LIQUIDITY SUPPORT: for CL pools (Uniswap V3/V4, PancakeSwap V3/Infinity CL, Aerodrome Slipstream, SushiSwap V3, Algebra forks like Camelot/THENA/QuickSwap, Fluid, Balancer V3) you can set a custom price range via tickLower/tickUpper — omit them for the protocol's default range. Classic pools (Curve, Balancer V2, Uniswap V2, Solidly) are also supported. Surplus returned to the user. Supports an optional affiliateCode (registered affiliate wallet address) forwarded to the API so the affiliate fee is paid on-chain to that address. IMPORTANT: The poolId parameter MUST come verbatim from the poolId field in the search_liquidity_pools response — do NOT construct or modify it. EXECUTION FLOW: (1) If the deposit token is non-native, send an ERC-20 approve to the router and WAIT for on-chain confirmation. (2) Call this tool again for a fresh quote (quotes expire). (3) Send the tx to the router contract: to=router, data=callData, value=value. This requires a private key or wallet signer. ⚠️ PRICE IMPACT: The response includes a priceImpact field. Agents MUST present this value to the user and request explicit confirmation before executing. ⚠️ ZERO OUTPUT: If an internal swap amount is too small, the API returns HTTP 400 with "swap amount too small: output rounds to zero". Increase the deposit amount.
| Name | Required | Description | Default |
|---|---|---|---|
| poolId | Yes | Pool identifier from search_liquidity_pools (e.g. 'pancakeswap-v3:0x36696...') | |
| sender | No | Wallet address of the sender (for simulation) | |
| chainId | Yes | EVM chain ID | |
| deposits | Yes | Tokens and amounts to deposit | |
| tickLower | No | Custom lower tick for concentrated liquidity | |
| tickUpper | No | Custom upper tick for concentrated liquidity | |
| affiliateCode | No | Optional affiliate wallet address registered on-chain with SwapWizard — forwarded to the API so the affiliate fee for this operation is paid to that address. Omit if you have no affiliate. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses mutational nature (single-transaction, requires approval, router call, quote expiry), error conditions, and priceImpact field. Provides execution flow and affiliate details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, important notes, execution flow, warnings). Slightly long but every sentence adds value; could be marginally tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers execution flow, error handling, and output usage (priceImpact). Without output schema, description compensates reasonably; could detail return format more but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond schema: explains poolId origin, deposits flexibility (any token), tick customization for CL pools, affiliateCode purpose, and sender role. Schema coverage is 100% but description enriches context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool builds a single-transaction zap to enter an LP position from any input token, and distinguishes from siblings like zap_out_of_lp_position and get_swap_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed usage steps (approve, fresh quote, send tx), warns about priceImpact and zero output, and specifies poolId must come from search_liquidity_pools. Does not explicitly mention when not to use this tool, but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
zap_out_of_lp_positionAInspect
Maps to POST /removeliquidity/quote. Builds a single-transaction zap to exit an LP position into ANY output token — you can withdraw into any token, not just the pool's underlying tokens. SwapWizard handles LP burn, fee collection, and intermediate swaps in a single transaction. Supports an optional affiliateCode (registered affiliate wallet address) forwarded to the API so the affiliate fee is paid on-chain to that address. REQUIRED WORKFLOW: First call list_user_lp_positions, then pass the returned fields (positionId, nftManager, dexName, liquidityKind) here along with sender, poolId, and withdrawals. EXECUTION FLOW: (1) APPROVE — For NFT-based positions, call setApprovalForAll(router, true) on the nftManager contract (do NOT use approve(router, tokenId)). For PCS Infinity BIN, call approveForAll(router, true). For classic LP pools (Curve, Balancer, Uniswap V2, Solidly), approve the LP token as a standard ERC-20. (2) WAIT for the approve tx to be confirmed on-chain. (3) Call this tool again for a fresh quote (quotes expire). (4) Send the tx to the router contract: to=router, data=callData, value=value. This requires a private key or wallet signer. ⚠️ PRICE IMPACT: The response includes a priceImpact field. Agents MUST present this value to the user and request explicit confirmation before executing.
| Name | Required | Description | Default |
|---|---|---|---|
| poolId | No | Pool identifier from search_liquidity_pools — pass if available. | |
| sender | Yes | Wallet address of the position owner. | |
| chainId | Yes | EVM chain ID | |
| dexName | No | DEX project name from list_user_lp_positions (e.g. 'Uniswap V3', 'PancakeSwap V3', 'curve-dex'). | |
| percent | No | Percentage of position to remove (default: 100). For classic LP pools (UniV2, Solidly, Curve, Balancer) use 99 instead of 100 to avoid reverts from LP balance race conditions between RPC nodes. | |
| nftManager | No | NFT position manager contract address from list_user_lp_positions. Required for CL positions (Uniswap V3/V4, PancakeSwap V3/Infinity CL, SushiSwap V3, Algebra). | |
| positionId | Yes | Position identifier from list_user_lp_positions. For CL positions: NFT token ID. For classic pools: LP token contract address. | |
| withdrawals | Yes | Tokens to receive after removal | |
| affiliateCode | No | Optional affiliate wallet address registered on-chain with SwapWizard — forwarded to the API so the affiliate fee for this operation is paid to that address. Omit if you have no affiliate. | |
| liquidityKind | No | Liquidity kind from list_user_lp_positions (e.g. UNIV3, UNIV4, ALGEBRA, SLIPSTREAM, PCS_INF_CL, CURVE, UNIV2, SOLIDLY). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully bears the burden. It discloses mutation (LP burn, fee collection, swaps), approval requirements per LP type, quote expiration, price impact display, and affiliate handling. It is comprehensive without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but efficiently structured with sections (REQUIRED WORKFLOW, EXECUTION FLOW, PRICE IMPACT). Every sentence adds necessary context; no redundancy. Slightly long but justified by tool complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 10 parameters, the description covers prerequisites, approval steps, execution flow, safety warnings, and edge cases like percent=99. It fully equips an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond schema: explains percent default and classic pool exception, distinguishes positionId for CL vs classic pools, and clarifies affiliateCode usage. This enrichment justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds a single-transaction zap to exit an LP position into any output token, with verb 'zap out' and resource 'LP position'. It distinguishes from siblings like 'zap_into_lp_position' and 'get_swap_quote' by specifying the exit action and flexibility of output tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit workflow is provided: 'REQUIRED WORKFLOW: First call list_user_lp_positions, then pass the returned fields...' It also includes execution flow with approval steps and a caution about price impact requiring user confirmation. This gives clear when-to-use and step-by-step guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!