SwapWizard MCP

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It details execution flow (approve, wait, fresh quote, send tx, requires private key/wallet signer), highlights PRICE IMPACT warning and ZERO OUTPUT error case, and states the output contains same router/callData/value fields as get_swap_quote. This is comprehensive behavioral disclosure.

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 sections for mapping, shortcut, use case, execution flow, warnings, and error case. It is front-loaded with key information. Some repetition occurs ('same as get_swap_quote' mentioned twice), but overall it efficiently covers necessary points without excessive length.

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 (9 params, 6 required, no output schema), the description covers behavior, use cases, execution flow, important warnings (price impact, zero output error), and relation to sibling tool. This provides complete contextual information for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. The description adds meaning by explaining the 'owner' parameter's role (wallet address whose LP positions will be excluded) and contextualizes the overall tool behavior related to parameters. It doesn't elaborate on every parameter, but the schema already covers them well, and the description adds value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool maps to POST /quote with excludePositions=true and explains it's a shortcut to get_swap_quote that excludes the caller's own LP position. It distinguishes from sibling get_swap_quote by specifying the use case (when agent holds significant position), making the purpose very clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: when an agent holds a significant position in the pool it is about to trade against (rebalancing, exit, treasury sizing). It also notes the tool returns the same execution fields as get_swap_quote, providing context. It does not explicitly mention when not to use, but the described use cases imply clear boundaries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully carries the burden. It discloses that the tool returns signable data only, never signs or broadcasts, and that it requires a private key or wallet signer for the final transaction. It also explains the behavior for non-native tokens (approve first, wait for confirmation), the exclusion of own LP positions, and the error condition for zero output. This is comprehensive behavioral disclosure.

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 clear sections (execution flow, warnings) and front-loads the key information (mapping to endpoint, what it returns). While it is somewhat lengthy, every sentence provides essential guidance for an AI agent. Minor redundancy could be trimmed, but overall it is efficiently written.

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 covers the main return fields (router, callData, value, price impact, route summary, gas estimate). It also addresses important contextual aspects: required prior approvals, the need for a fresh quote, auth requirements, and error handling for zero output. The only missing piece is a more detailed listing of all possible response fields, but the essential ones are mentioned.

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%, so the baseline is 3. The description adds value beyond the schema by explaining the excludePositions parameter in detail (its purpose and where to get the data from list_user_lp_positions). It also provides context for the amount parameter being a stringified uint256, but this is already in the schema. The extra context for excludePositions justifies a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: mapping to POST /quote and returning the best swap quote across all integrated DEX protocols with specific fields like router, callData, value, price impact, route summary, and gas estimate. It distinguishes from siblings by noting it supports the excludePositions parameter and returns signable data only, never signing or broadcasting, which differentiates it from potential execution tools like 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?

The description provides a clear execution flow (approve, get fresh quote, send tx) and explicit warnings about price impact and zero output scenarios. It tells agents when to present price impact to users and request confirmation. However, it does not explicitly differentiate from the sibling get_clean_quote, leaving some ambiguity about when to use which.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

As there are no annotations, the description carries full behavioral disclosure. It explains the multi-protocol discovery, optional Alchemy acceleration, fallback to on-chain scanning, and latency for new positions. It does not cover error handling or authentication requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed but well-organized: starts with core function, lists protocols, output fields, optimization, fallback, and a critical usage warning. Every sentence adds value, though slightly longer than necessary.

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 lists returned fields. It covers core functionality, optimization, and integration with a sibling tool. Minor gaps: no mention of pagination or error states.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining how rpcUrl can be used for faster results and describing fallback behavior, going beyond the schema's simple type description.

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 for a wallet on a chain, maps to GET /positions, and distinguishes itself from the sibling tool by explicitly saying to call this before 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 clear guidance on when to use this tool (before zap_out_of_lp_position) and optimization tips (using Alchemy RPC URL). However, it does not explicitly contrast with other siblings like search_liquidity_pools or analyze_pool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description effectively discloses behavioral details: HTTP method, default sorting, pagination, and critically warns about two ID fields and their distinct uses. It lacks rate limit info but covers core 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 well-structured with a KEY PARAMETERS section and a warning. It is fairly long but every sentence adds value, and the most critical info is front-loaded.

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 14 parameters, no output schema, and no annotations, the description covers essential aspects: role, key params, ID field distinction, and pagination. It could include pagination metadata 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?

Despite 100% schema coverage, the description adds significant value by explaining key parameters like trending, sortBy, sortOrder, and topPerVenue with usage examples and defaults, beyond the schema's minimal 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 the tool maps to GET /pools and discovers liquidity pools, explicitly listing returned fields. It distinguishes from siblings by noting 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?

It provides key parameter usage with defaults (e.g., default sort is tvl desc) and explicitly states it is required before zap tools. It does not explicitly exclude cases, but the context is clear for discovery.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavioral traits: it handles intermediate swaps via SwapWizard, supports multiple DEXes, returns surplus, requires two-step execution (approve wait then fresh quote), price impact presentation, and error behavior (HTTP 400 for small amounts). It also notes that quotes expire.

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 sections (EXECUTION FLOW, IMPORTANT, PRICE IMPACT, ZERO OUTPUT) and bold warnings. It is somewhat lengthy but all parts are informative. A slight reduction in redundancy could improve conciseness, but it's effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 params, no output schema), the description is thorough: covers input constraints, step-by-step execution, error handling, user interaction (price impact confirmation), and dependencies on other tools (search_liquidity_pools). No critical gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds significant context beyond the schema: e.g., poolId constraint, token address format (0x0000 for native), amount as stringified uint256, tickLower/tickUpper for concentrated liquidity, affiliate code usage. It enriches each parameter's meaning.

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's purpose: building a single-transaction zap to enter an LP position from any input token, mapping to POST /addliquidity/quote. It clearly distinguishes from sibling tools like 'zap_out_of_lp_position' by focusing on entering 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?

The description provides explicit usage guidance: the poolId must come verbatim from search_liquidity_pools, execution flow steps (approve then call again), requirement to present price impact to user, and handling of zero output errors. It also implies when not to use (e.g., when deposit token is one of pool's underlying tokens, but still works).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; the description carries full burden. It details the single-transaction nature, approval requirements per LP type, the need for a wallet signer, quote expiration, and the price impact warning. It also explains the percent race condition for classic pools.

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. Every sentence adds value given the tool's complexity. It could be slightly more concise but remains efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description mentions the priceImpact field and the router contract details (to, data, value). It covers the complete workflow from prerequisites to execution, making it self-contained for a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%. The description adds critical context beyond schema: explains where to obtain positionId, nftManager, dexName, liquidityKind from list_user_lp_positions; specifies that percent should be 99 for classic pools to avoid reverts; and clarifies parameter differences between CL and classic positions.

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 /removeliquidity/quote and builds a single-transaction zap to exit an LP position into any output token. It distinguishes from sibling tools like zap_into_lp_position and 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?

The description provides a full REQUIRED WORKFLOW (calling list_user_lp_positions first) and EXECUTION FLOW with approval steps, waiting for confirmation, fetching a fresh quote, and sending the transaction. It explicitly states to present priceImpact to the user before execution.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.