DeFi execution layer for AI agents — swap, zap in/out of LP positions, and route across AMMs on 5 EVM chains. Non-custodial: returns signable calldata, never signs.
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.
Average 4.4/5 across 11 of 11 tools scored. Lowest: 3.9/5.
Each tool has a clearly distinct purpose: pool analysis, health check, quotes (standard and clean), setup guide, chain/DEX info, LP position listing, pool search, and zap in/out. No two tools overlap in functionality.
All tool names use snake_case, but the verb prefixes are not uniform: some use 'get_*', others use 'analyze_', 'check_', 'list_', 'search_', 'zap_'. While still clear, a more consistent prefix pattern would improve predictability.
11 tools cover the full scope of a DeFi liquidity management server: discovery, analysis, quoting, entry/exit, and auxiliary info. No redundant tools, and the count is well within the optimal range.
The tool surface covers all essential operations for liquidity management: pool search and analysis, swap quotes, position listing, and single-transaction zap in/out. No critical gaps are evident.
analyze_poolAInspectMaps 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses caching behavior (10 minutes, refreshed on-demand) and data source (GeckoTerminal). No annotations present, but description does not mention error handling or rate limits, which would be helpful.
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 sentences, each providing distinct value (API mapping, returned data, caching, parameter source). Front-loaded with key action. No fluff.
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 simple tool (1 param, no output schema), the description covers all necessary aspects: what it returns, caching, parameter source. No gaps evident.
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 a clear description. The tool description adds extra context by linking the id to search_liquidity_pools and emphasizing it's numeric.
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 returns real-time momentum data for a specific pool, listing specific metrics (volume, price changes, etc.). It distinguishes from sibling search_liquidity_pools by explicitly mentioning to use its id field.
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 clear usage context: use when you have a pool id from search_liquidity_pools. Does not explicitly state when not to use, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_api_healthAInspectMaps to GET /health. Returns service availability. Use to confirm the API is responsive before attempting operations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description covers the basic behavior but does not detail the response format. However, for a simple health check, this is adequate.
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 fluff. Front-loaded with endpoint mapping and usage instruction.
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 simplicity (no parameters, no output schema), the description is complete and 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?
No parameters exist, so the description does not need to add parameter semantics. Baseline 4 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?
Clearly states the tool maps to GET /health and returns service availability. It is distinct from sibling tools which deal with swaps and 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?
Explicitly says to use it to confirm the API is responsive before operations, providing clear 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_quoteAInspectMaps 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, details execution flow (approve, quote, send tx), warns about price impact and zero output error. Execution flow description could be misinterpreted as the tool executing the swap rather than returning a quote, but overall covers key behaviors.
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, usage, execution, warnings). Front-loaded with key info. Slightly verbose but every sentence adds value, especially the warnings.
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?
Comprehensive given 9 parameters and no output schema: covers when-to-use, execution flow, error scenario, and price impact. Relies on knowledge of get_swap_quote for response format, which is acceptable.
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 3. Description adds minimal extra meaning beyond schema, except for affiliateCode explanation and default slippage. Not enough to raise the score.
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?
Clearly states it maps to POST /quote with excludePositions=true and is a shortcut to get_swap_quote. Explicitly differentiates from sibling by specifying the use case: pricing swaps excluding the caller's own LP position for concentrated-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 when to use: when holding significant position in the pool (rebalancing, exit, treasury sizing). Mentions execution flow and affiliateCode. Does not explicitly say when not to use but implies using get_swap_quote otherwise.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_setup_guideAInspectReturns 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the tool returns a guide covering configuration and procedures. It implies no side effects, and the listed contents clarify what the tool provides. Could be more explicit about safety, but 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 dense sentences followed by a list. Front-loaded with purpose and usage. Every sentence adds value, no redundancy.
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 simple zero-parameter tool, the description fully explains its purpose, usage order, and coverage. No missing context.
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 in schema, so baseline 4 applies. Description adds no parameter info, but none is needed.
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?
Explicitly states it returns the setup guide and should be called first. Distinguishes from operational sibling tools by specifying it as a prerequisite guide.
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?
Clearly instructs 'Call this FIRST before using any other tool', providing strong usage guidance. Does not explicitly mention when not to use, but the instruction is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_supported_chainsAInspectMaps 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It notes 'Maps to GET /chains' (implying HTTP method), but does not explicitly state that the tool is read-only, idempotent, or free of side effects. The behavioral transparency is adequate but not rich.
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 a single, front-loaded sentence that efficiently conveys the HTTP mapping, purpose, and output details. Every word earns its place with no redundancy.
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?
There is no output schema, yet the description only lists example chains and mentions 'chain IDs and native gas tokens' without specifying the exact structure (e.g., array of objects, field names). While adequate for a simple listing, additional structure detail would improve completeness.
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, so schema coverage is 100%. The description adds value by clarifying the output content (chain IDs, native gas tokens, examples), which goes beyond the empty schema.
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 explicitly states the tool lists supported EVM chains with chain IDs and native gas tokens, and provides concrete examples (Ethereum, Arbitrum, Base, Polygon, BNB Chain). This clearly differentiates it from sibling tools like analyze_pool 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 does not provide explicit guidance on when to use this tool versus alternatives. However, given its zero parameters and simple listing purpose, the usage context is implied; there is no exclusionary or alternative tool mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_supported_dexesAInspectReturns 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It states the tool returns data (DEX sources) but does not explicitly state it is read-only or side-effect free. While not misleading, it could be more explicit about safety.
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: the first states the purpose, the second adds critical usage detail. No redundant words, every sentence earns its place.
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 has one optional parameter and no output schema, the description fully covers its functionality (what it does, what it returns, and how to use the output). It is complete for an agent to correctly select and invoke it.
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 input schema describes chainId with a decent description (filter by chain ID, omit for all). Schema description coverage is 100%, so baseline is 3. The description adds value beyond schema by explaining the return format (display name + slug) and how to use the slug, raising the score to 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 the tool returns AMM/DEX sources that SwapWizard routes across per chain, specifying each DEX includes display name and slug. It distinguishes purpose by linking the slug to filter pools in search_liquidity_pools, a sibling tool.
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 clear context for when to use this tool (to get supported DEX sources) and explicitly instructs how to use the returned slug as a filter for search_liquidity_pools. It does not explicitly mention exclusions or alternatives, but the cross-reference is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_swap_quoteAInspectMaps 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses read-only nature (returns signable data, never signs/broadcasts), explains approval flow, and warns about potential errors.
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 front-loaded purpose and bullet points. Slightly verbose but organized effectively with warnings and flow.
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?
Despite no output schema, description details return fields and execution requirements. Complex tool with 8 params is fully explained, including error handling and prerequisite steps.
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%, baseline 3. Description adds value with context on affiliateCode registration and excludePositions source (list_user_lp_positions), justifying 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 the tool returns a swap quote from integrated DEX protocols, listing specific fields. It differentiates by mentioning 'best swap quote across all integrated DEX protocols,' distinguishing from siblings like get_clean_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 execution flow with steps, warnings about price impact and zero output. Lacks explicit comparison to sibling tools but gives clear context for when to 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_positionsAInspectMaps 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it performs a read operation, uses Alchemy API for speed but falls back to on-chain scanning, and notes that newly created positions may take longer to appear. It also details output fields and the meaning of momentumSignal, providing complete 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with multiple paragraphs covering purpose, output, signals, and technical notes. However, it is long and could be more concise without losing critical information. Medium conciseness.
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?
Without an output schema, the description thoroughly explains return values including positionId, nftManager, dexName, tokens, fees, and momentum signals. It also provides exit decision context and cross-references other tools, making it complete for an agent to use effectively.
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 input schema already has 100% description coverage for all three parameters. The description adds some extra context about using an Alchemy RPC for performance but does not significantly enhance the meaning beyond the schema. Baseline of 3 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 reads all LP positions a wallet holds on a given chain via GET /positions. It specifies supported protocols and output fields, and distinguishes itself from sibling tools like zap_out_of_lp_position by explicitly stating it should be called before that tool.
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 clear usage context: always call before zap_out_of_lp_position, and mentions performance implications of using an Alchemy RPC vs. fallback. It also references sibling tool search_liquidity_pools for entry signals. While not explicitly stating when not to use, the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_liquidity_poolsAInspectMaps 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations provided, description carries full burden. Discloses that poolId must be passed as-is to zap tools, feeAprEstimate extrapolates short windows and can be extreme, momentumSignal has entry/watch/exit states, suggestedRangePct is for zap_into_lp_position, and 5m window signal is hourly context. Also explains hookless excludes pools with custom hooks that can add fees/restrictions.
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?
Description is long but well-structured with sections (key parameters, momentum signal). Every sentence adds value; no fluff. Could be slightly more concise but justifiable given 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?
Extremely complete: covers return fields, parameter behaviors, relationships with sibling tools (zap_into_lp_position, list_user_lp_positions, analyze_pool), caveats (feeAprEstimate extrapolation), and usage examples. No obvious gaps given no output schema and 17 parameters.
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 description coverage is 100%, baseline 3. Description adds significant value beyond schema: explains trending/timeframe interaction, momentumSignal in detail, sorting with signal groups pools by momentum, and gives usage examples. Some overlap with schema descriptions (e.g., signal parameter already mentions trending), but overall enhances 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 it discovers liquidity pools across supported AMMs and chains, listing return fields like id, poolId, symbols, etc. It distinguishes from sibling tools by specifying that poolId is for zap tools and id is for analyze_pool, and that it's a required upstream step before zap_into_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?
Provides explicit when-to-use: 'Required upstream step before zap_into_lp_position.' Gives specific parameter combinations for entering pools (trending: true, timeframe: "6h", signal: "entry", sortBy: "signal", sortOrder: "desc") and for exiting (read momentumSignal on list_user_lp_positions). Explains when to use 6h vs 1h timeframe.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
zap_into_lp_positionAInspectMaps 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully discloses behavior: it is a mutation (POST), requires approvals, returns a quote that expires, needs private key/wallet signer, handles price impact, and can error with 'swap amount too small'. It also explains the inclusion of intermediate swaps, price-range setup, and surplus return.
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 but well-structured, starting with API mapping, core feature, CL support, execution flow, and warnings. Most sentences add value, though some repetition ('any input token' restated) could be trimmed. Still, it remains focused and useful.
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 complex tool with no output schema or annotations, the description covers purpose, parameters, execution steps, error conditions, and warnings. It mentions priceImpact in the response but could elaborate on the full response structure. Still, it provides sufficient context for an agent to use the tool effectively.
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, but the description adds significant extra meaning: explains poolId must be verbatim from search result, tickLower/tickUpper usage for CL pools, deposits token address format (0x0000...0000 for native), and affiliateCode purpose. This goes well beyond the schema.
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 /addliquidity/quote and builds a single-transaction zap to enter an LP position from any input token. It distinguishes from siblings like zap_out_of_lp_position and get_swap_quote by emphasizing that the deposit token does not have to be a pool underlying token and that it handles all intermediate swaps plus LP mint in one transaction.
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 extensive guidance on when to use (e.g., for entering LP positions, supporting both CL and classic pools), execution flow (approvals, fresh quotes, sending tx), and important constraints (poolId must be verbatim from search_liquidity_pools). It does not explicitly state when not to use it or compare to alternatives like get_swap_quote, but the context is very clear.
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_positionAInspectMaps 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully covers behavior: it details the entire approval process (setApprovalForAll vs approve), explains that quotes expire, warns about price impact on-chain, and describes the affiliate fee mechanism. This is comprehensive with 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?
The description is long but well-organized into sections (purpose, workflow, execution flow, warning). Every sentence adds necessary information for a complex multi-step tool. However, it could be slightly more concise without losing clarity.
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 10 parameters, no output schema, and no annotations, the description covers all essential aspects: workflow prerequisites, execution steps, parameter relationships, safety warnings, and expected response fields (priceImpact). It is fully adequate for an agent to use 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 the description adds significant meaning beyond the schema: it explains that parameters like positionId, nftManager, dexName, liquidityKind come from list_user_lp_positions, provides specific guidance for 'percent' (use 99 for classic pools), and clarifies affiliateCode usage. This greatly enhances 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 explicitly states it 'builds a single-transaction zap to exit an LP position into ANY output token', clearly distinguishing it from sibling tools like 'zap_into_lp_position' (entry) and 'list_user_lp_positions' (listing). The verb 'exit' and resource 'LP position' are specific.
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 REQUIRED WORKFLOW with steps (first call list_user_lp_positions, then pass fields), and execution flow with approval details. It guides when to use this tool but does not explicitly state when not to use it or compare to alternatives beyond the workflow.
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.
No comments yet. Be the first to start the discussion!
