SwapWizard MCP
Server Details
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.
- 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.5/5 across 11 of 11 tools scored.
Each tool targets a distinct operation: health check, setup, chain/DEX info, pool search, pool analysis, swap quoting, LP position listing, and both entering/exiting LP positions. There is no overlap between tools.
Tool names use a mix of 'get_', 'list_', 'search_', 'analyze_', 'check_', and 'zap_into/out'. While mostly readable and internally consistent (e.g., zap_into vs zap_out), the pattern is not uniform across all tools.
With 11 tools, the server covers core DeFi operations (swap, LP management, analysis) without being bloated. The count is well within the ideal 3-15 range for a focused server.
The tool set covers the essential lifecycle: pool discovery, pool analysis, swap quoting, LP position listing, and LP position entry/exit. Minor gaps like token metadata queries exist but do not hinder core workflows.
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?
The description discloses the caching behavior (10-minute cache, stale entries refreshed on-demand), which is beyond what annotations would provide (none provided). It implies a read-only operation but does not mention error handling or requirements like pool existence.
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 concise (5 sentences) and front-loaded with the most critical information: endpoint mapping, then data summary, then caching, then usage instruction. Every sentence adds value 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?
Given only one parameter and no output schema, the description covers the key behavioral aspects (data returned, caching). However, it lacks error scenarios or what happens if the pool id is invalid, which would be helpful for 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?
Schema coverage is 100% and the description adds meaningful context by specifying that the id comes from search_liquidity_pools response, which helps the agent correctly derive the value. The schema description is already clear, but the tool description adds integration insight.
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 verb ('Returns') and the resource ('real-time momentum data for a specific pool'), listing specific data fields like volume, price changes, transactions, etc. It distinguishes itself from sibling tools like search_liquidity_pools by specifying that this tool returns momentum data for a single pool.
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 clearly instructs to use the numeric id field returned by search_liquidity_pools, providing a direct dependency. It implicitly advises to call search_liquidity_pools first, but does not explicitly state when not to use this tool or provide alternative scenarios.
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?
No annotations provided, so description carries full burden. Describes a read-only operation (GET) and returns availability. Could elaborate on response format, but sufficient given simplicity.
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 short sentences, front-loaded with endpoint mapping. 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?
No output schema; description does not describe the response format (e.g., status code, boolean). Adequate for a simple health check but could be more 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?
Zero parameters, schema coverage 100%. Description adds no parameter info, but none needed. Baseline 4 applies.
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 GET /health and returns service availability. Distinct from siblings which are all trading/liquidity tools.
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 'use to confirm the API is responsive before attempting operations', which provides clear usage context. No exclusion given, but the use case is self-contained.
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?
With no annotations provided, the description carries full burden and excels. It explains the API behavior (excludePositions=true), execution flow (approve, quote, send tx), error conditions (HTTP 400 for zero output), price impact warning, and optional affiliateCode usage. This provides complete behavioral transparency.
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 each sentence adds value. It is front-loaded with the key purpose and structured with sections: mapping, use case, return fields, execution flow, and warnings. Minor redundancy (e.g., mentions affiliateCode twice) keeps it from a 5.
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 fields (router/callData/value execution fields, priceImpact), error conditions, and execution flow. It covers all necessary context for an agent to invoke this 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% (baseline 3). The description adds value by explaining the 'owner' parameter as 'wallet address whose LP positions will be excluded', 'amount' as 'stringified uint256 in token decimals', and 'affiliateCode' as optional affiliate wallet. This goes beyond the 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 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 the resource (quote) and the action (get clean quote for concentrated-liquidity positions). It distinguishes from get_swap_quote by explaining the exclusion behavior.
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 an agent holds a significant position in the pool it is about to trade against ... needs a quote unaffected by its own liquidity.' It also provides execution flow and caveats. It does not explicitly contrast with alternatives beyond get_swap_quote, but the use case 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 are provided, so the description must fully disclose behavior. It transparently describes the tool as a read-only guide covering configuration, flows, and rules. The description implies non-destructive, informational behavior.
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 concise, but the listing of covered topics could be slightly more condensed. However, it is well-structured and front-loaded with the critical instruction to call first.
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 fully covers what the tool does and what it contains. An agent would have sufficient context to use it 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?
The tool has zero parameters, so the baseline is 4. The description does not need to add parameter meaning as none exist.
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 a complete setup and usage guide for SwapWizard. It specifies the resource (setup and usage guide) and the action (returns), leaving no ambiguity about the tool's purpose.
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 instructs to call this tool first before any other tool, providing clear guidance on when to use it. This is a strong usage directive.
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 carries the burden. It mentions it maps to GET /chains, implying a read-only operation, but does not explicitly state safety, authentication needs, or rate limits. For a simple list, it 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 concise with a single sentence front-loading the endpoint. No unnecessary 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?
Though no output schema, the description explains what the tool returns (chain IDs and native gas tokens) and gives examples. For a simple list tool, this is 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?
There are no parameters, so baseline is 4. The description adds value by listing example chains and what is returned (chain IDs and gas tokens), 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 states it lists supported EVM chains with chain IDs and native gas tokens, mapping to GET /chains, and provides examples. It clearly distinguishes from sibling tools that deal with pools, quotes, etc.
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 implicitly indicates this tool is for retrieving a list of chains. While it doesn't specify when not to use or alternatives, the purpose is straightforward and no exclusions are needed.
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 carries full burden. It explains the tool returns a list of DEX sources with details and optional filter by chainId. It is straightforward and sufficiently transparent for a simple read-only 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?
The description is two concise sentences, front-loaded with the purpose and followed by a practical usage hint. No extraneous 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 no output schema, the description explains the return values (display name and slug) and the optionality of chainId. Slight lack of exact structure but still sufficient for using 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?
The input schema already provides a complete description for the single optional parameter chainId. The tool description does not add additional semantic information beyond what the schema already conveys.
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, and explains the output includes display name and slug. It distinguishes from sibling tools like search_liquidity_pools by showing how it's used as input.
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 a direct use-case hint (use slug as 'project' filter in search_liquidity_pools), establishing clear context. It could be more explicit about when not to use this tool, but it's mostly clear.
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, so description carries full burden. It fully discloses that it never signs or broadcasts, quotes expire, and includes details about error cases (HTTP 400) and price impact warnings for user consent. 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?
Well-structured with clear sections (execution flow, warnings) and use of emojis for emphasis. However, it is somewhat verbose and could be trimmed without losing meaning.
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 return fields (router, callData, value, price impact, etc.) and error scenario. No output schema, but description lists key outputs. Minor gap: does not describe exact response structure or provide example.
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 value by explaining affiliateCode as optional, excludePositions source, slippageBps default, and side meaning. This provides useful context beyond basic 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 it returns the best swap quote from DEX protocols, including specific details like affiliate support and excludePositions. It distinguishes from siblings by mentioning these features, but does not explicitly differentiate from '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 a clear execution flow (approve, requote, send tx) and warns about price impact and zero output. However, it does not explicitly compare with sibling tools like 'get_clean_quote' for alternative scenarios.
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?
No annotations provided, so description carries full burden. Reveals read-only nature, fallback behavior when no Alchemy key, and composite return signals (momentumSignal). Missing error handling and auth details, but key behaviors are disclosed.
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. Some verbosity, but every sentence adds value. Could be slightly more concise, but organization is strong.
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 read tool with no output schema or annotations, the description is remarkably complete: covers return fields, signal interpretation, performance trade-offs, and cross-tool relationship. Enough for an agent to invoke 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% with clear descriptions. The description adds value by explaining how rpcUrl from Alchemy accelerates discovery, which is beyond the schema. Other parameters are reinforced without redundancy.
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 /positions and reads all LP positions a wallet holds on a given chain, listing many supported protocols. It distinguishes from siblings by referencing 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?
Provides explicit guidance: use to drive exit decisions mirroring entry signals from search_liquidity_pools, always call before zap_out_of_lp_position, and suggests using Alchemy RPC for speed. Context for alternatives is clear.
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 provided, but the description fully discloses behavior: it explains the two ID fields (poolId vs id), feeAprEstimate extrapolation, momentum signal derivation (5m window uses hourly context), and hooks implications. Clearly states what the tool does and its limitations.
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 front-loaded mapping and clear sections for key parameters, example usage, and ID field notes. It is lengthy but justified by the tool's complexity; however, some verbosity could be trimmed 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?
Despite no output schema, the description covers all important output fields (momentumSignal, suggestedRangePct, feeAprEstimate) and explains their meaning. It relates to sibling tools (e.g., upstream of zap_into_lp_position) and provides complete guidance for effective use.
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 significant value by explaining each parameter's role, such as trending, timeframe, signal, sortBy, hookless, and topPerVenue. Includes usage examples and constraints like feeAprEstimate only in trending mode.
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 GET /pools, discovers liquidity pools across AMMs and chains, and is an upstream step before zap_into_lp_position. It distinguishes from siblings like analyze_pool and checks for exits via list_user_lp_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?
Provides explicit instructions for finding entry pools with trending, timeframe, signal, sortBy, and sortOrder. Advises reading momentumSignal on list_user_lp_positions for exits. Explains feeAprEstimate's extrapolation risk and when to use hookless, topPerVenue, and sort options.
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?
No annotations provided, but the description thoroughly explains the tool's behavior: handles intermediate swaps, LP mint, price-range setup in one transaction, supports concentrated liquidity and classic pools, returns surplus, warns about price impact and zero output, and notes the need for a private key/wallet signer. Could explicitly state it's a state-changing transaction.
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 lengthy but well-structured with clear sections (endpoint mapping, functionality, concentrated liquidity, execution flow, warnings). Every sentence adds value, though minor redundancy exists.
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 (7 parameters, no output schema), the description covers what the tool does, how to use it, prerequisites, error conditions, and execution steps. It could mention the response structure more explicitly, but is largely 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% with descriptions for all 7 parameters. Description adds extra context for poolId (must come from search_liquidity_pools), tickLower/tickUpper (optional, for CL pools), and affiliateCode (optional, registered address), providing meaning 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, distinguishing it from siblings like zap_out_of_lp_position and 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 explicit guidance on when to use (entering an LP position), detailed execution flow (approve, get fresh quote, send tx), and warnings about price impact and zero output. Lacks explicit comparison to alternatives but purpose is clear enough.
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?
Discloses that the tool requires wallet signer, approval steps, transaction sending, and that quotes expire. Warns about price impact and the need for user confirmation. No annotations provided, so description carries full burden and meets it thoroughly.
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 sections and bullet points, but slightly verbose in some parts (e.g., affiliateCode explanation could be shorter). Front-loaded with purpose and key workflow.
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 10 parameters and no output schema, the description covers workflow, parameter nuances, approval requirements, and safety warnings. Nearly all necessary context is present.
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 significant context: explains percent behavior for classic pools, clarifies positionId and nftManager based on pool type, and notes poolId optionality. This goes 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?
Clearly states the tool builds a single-transaction zap to exit an LP position into any output token, distinguishing it from zap_into_lp_position and other swap/analysis tools.
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 and EXECUTION FLOW with step-by-step instructions, including calling list_user_lp_positions first, approval distinctions, waiting for confirmation, obtaining a fresh quote, and sending the transaction. Also advises on user confirmation for price impact.
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!