SwapWizard

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

With no annotations provided, the description carries the full burden. It discloses caching behavior ('cached for 10 minutes; stale entries are refreshed on-demand') and specifies the returned data fields. It does not mention error handling or rate limits, but the disclosed behavior is valuable and non-obvious.

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 three sentences, front-loaded with endpoint mapping, then data details, then caching and usage tip. Every sentence contributes information without redundancy, making it concise and well-structured.

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 having no output schema, the description lists the key return fields (volume, price changes, transactions, traders, reserve) and explains caching behavior. It also provides usage context via the search prerequisite, making it complete for a single-parameter read-only 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 coverage is 100% and the parameter description already states 'Pool numeric ID (from the id field in search_liquidity_pools response)'. The description repeats this same information without adding new semantics, so it meets the baseline of 3 but does not exceed it.

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 real-time momentum data for a specific pool from GeckoTerminal' and maps to a specific endpoint 'GET /pools/analyze/:id'. It lists specific data categories (volume, price changes, transactions, traders, reserve), distinguishing it from search_liquidity_pools and other siblings.

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 by instructing to 'Use the numeric id field returned by search_liquidity_pools', implying a prerequisite and usage sequence. It does not explicitly mention alternatives or when not to use, but the context is sufficient for a 4.

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 the burden. It discloses the endpoint mapping and that it returns service availability, which is sufficient for a simple health check. It does not elaborate on response structure or potential failure modes, but the low complexity limits the need.

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 short, focused sentences. Front-loaded with the endpoint, then the return value, and finally usage guidance. No wasted words.

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

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

Given the tool's simplicity (no parameters, no output schema), the description is fully adequate. It states what the tool does, how to use it, and when to call it. The context is complete for an agent to select and invoke 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 description need not add parameter details. Baseline for no parameters is 4. The description's mention of the health endpoint complements the schema's emptiness.

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 /health and returns service availability, which is a specific verb and resource. It is easily distinguished from sibling tools that handle DeFi operations like quotes and 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?

Explicitly states 'Use to confirm the API is responsive before attempting operations,' giving clear when-to-use guidance and implying it should precede other operations. No alternatives 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?

No annotations are provided, so the description carries full burden. It thoroughly discloses the execution flow (approve, fresh quote, send tx), the requirement of a private key/signer, the priceImpact field that must be presented to the user, and the HTTP 400 zero-output error case. This goes well beyond basic descriptions.

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 longer than average but well-structured: purpose first, then usage, execution flow, and clearly highlighted warnings. Every sentence contributes value; warnings are appropriately prominent. Slightly verbose but justified by the 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?

While no output schema exists, the description references get_swap_quote for return fields, which is acceptable given the sibling context. It covers key edge cases (zero output) and human oversight requirements (priceImpact). It could be more complete if it listed the exact response fields or prerequisites, but the sibling reference and warnings make it fairly comprehensive.

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%, providing full parameter details. The description adds minimal extra parameter meaning: it mentions affiliateCode is forwarded and owner is the excluded wallet, but these are already in the schema. No additional syntax or format insights.

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 POST /quote with excludePositions=true and is a shortcut to get_swap_quote that excludes the caller's own LP position. It distinguishes itself from get_swap_quote by the exclusion behavior and focused LP-avoidance use case.

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: '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.' It also contrasts with the standard get_swap_quote, implying when not to use.

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 the full burden. It transparently states what the tool returns (a guide) and enumerates the topics covered (configuration, operational flows, transaction details, approval rules). It does not claim any side effects or mutations, and the 'call first' instruction implies a safe, non-destructive operation. Lacks explicit mention of read-only or lack of side effects, but that is likely obvious for a guide 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 very concise, consisting of two sentences. The first sentence gives the purpose immediately, and the second lists high-value content areas without unnecessary filler. Front-loaded with 'Call this FIRST,' which is the most critical 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?

For a no-parameter, no-output-schema tool, the description is complete. It clearly explains what the guide covers and instructs on when to call it. It even provides a mini-table of contents (configuration, poolId usage, operational flows, transaction execution, approval rules) which leaves no ambiguity about what the agent will learn.

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 adds no parameter details, but none are needed. The schema coverage is effectively 100% (no parameters).

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

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

The description clearly states the tool returns the complete setup and usage guide for SwapWizard, using a specific verb and resource. It distinguishes itself from sibling tools by declaring itself the introductory/guide tool, unlike the specific action tools (swap, zap, 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?

Explicitly instructs 'Call this FIRST before using any other tool,' providing clear when-to-use guidance. This distinguishes it from alternatives and establishes it as the prerequisite step, which is exactly the kind of usage direction 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?

No annotations are provided, so the description carries the burden. It explicitly states the HTTP mapping to GET /chains, implying a read-only operation, and specifies what is returned (chain IDs and native gas tokens). It does not mention auth or rate limits, but for a public list endpoint this is acceptable.

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

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

Two sentences, no wasted words, and the key information is front-loaded with the API mapping and purpose. Perfectly sized for the tool's simplicity.

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?

Low complexity with no parameters and no output schema. The description sufficiently conveys the tool's purpose and the nature of its response. Minor gap: no mention of response format or whether all chains are always included, but these are not critical for a simple list 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?

The tool has 0 parameters, so the baseline is 4. The description adds value by explaining the return payload (chains with IDs and gas tokens), which is more than the empty schema alone could provide.

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 lists supported EVM chains with chain IDs and native gas tokens, using a specific verb and resource. Provides examples (Ethereum, Arbitrum, Base, Polygon, BNB Chain) and distinguishes from sibling tool get_supported_dexes by focusing on chains versus DEXs.

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?

Implies usage when chain information is needed but does not explicitly contrast with alternatives like get_supported_dexes. No explicit when-or-when-not guidance, but the simplicity of the tool makes the intended use reasonably 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 carries the full burden of behavioral disclosure. It states that each DEX includes its display name and slug, giving insight into the return structure. It doesn't mention side effects or limitations, but as a read-only list tool, the disclosed behavior 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?

The description is two sentences long, with no wasted words. The first sentence states the purpose, the second explains the slug format and cross-tool usage. 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?

For a tool with one optional parameter and no output schema, the description is sufficiently complete. It covers the purpose, the output content, and how the output connects to another tool. No critical information is missing for an agent to select and 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?

The schema already provides 100% coverage for the single parameter (chainId) with a description of its behavior. The tool description adds no additional parameter semantics beyond the schema, so a baseline score 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's function: 'Returns the AMMs / DEX sources SwapWizard routes across per chain.' It uses a specific verb ('returns') and identifies the resource (AMMs/DEX sources). It also distinguishes itself from the sibling tool search_liquidity_pools by explaining that the returned slugs are used as filters there.

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 gives explicit guidance on how to use the output: 'use the slug as the ‘project’ filter in search_liquidity_pools to filter pools by protocol.' This contextualizes the tool relative to a sibling. However, it doesn't explicitly state when to call this tool instead of others, though the relationship is implied.

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 the full burden and does so excellently. It discloses that the tool returns signable data only and never signs/broadcasts, warns about quotes expiring, requires on-chain approval confirmation, mandates user confirmation for price impact, and explains the zero-output error case. These are critical behavioral traits beyond the basic function.

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 every sentence earns its place. It is front-loaded with the core purpose, then flows into execution steps and warnings in a clearly numbered section. The structure (EXECUTION FLOW, PRICE IMPACT, ZERO OUTPUT) makes it scannable and appropriately sized for a complex swap tool with 8 parameters and no annotations.

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 lists the key response fields (router, callData, value, price impact, route summary, gas estimate). It covers prerequisites (approval), lifecycle (quotes expire), safety (price impact confirmation), and error handling (zero output 400). This is a complete contextual picture for an agent to invoke the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds extra meaning for affiliateCode (how to get one, on-chain fee payment) and excludePositions (how to obtain from list_user_lp_positions, purpose of excluding self-impact). It also clarifies that amounts are stringified uint256 and native coin is zero address, but those are in schema. Overall, it supplements but does not fully replace schema knowledge.

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 opens with a specific verb+resource: 'Returns the best swap quote across all integrated DEX protocols.' It lists the concrete response fields (router, callData, value, price impact, etc.) and distinguishes this quote tool from siblings like get_clean_quote by emphasizing the complete execution payload. The purpose is immediately clear and unambiguous.

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 detailed execution flow with explicit steps: approve ERC-20, call again for fresh quote, send tx with router/callData/value. It also notes the need for private key or wallet signer. It references list_user_lp_positions for excludePositions, but does not explicitly contrast with get_clean_quote or state when NOT to use this tool. Thus it gives strong context without explicit exclusions.

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 and does so well: it discloses read-only nature ('Reads'), fallback behavior/slowness without Alchemy, the semantics of momentumSignal (including absence meaning momentum exhausted), and the full list of returned fields. No contradictions with annotations (none provided).

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-structured with clear sections (purpose, protocols, response fields, EXIT SIGNAL, performance note, IMPORTANT integration note). Every sentence carries practical information, though a few phrases feel slightly repetitive (e.g., 'Reads' and 'reads all LP positions'). Overall, it earns its 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 no output schema, the description fully compensates by enumerating returned fields, explaining the momentum/exits semantics, describing failure/fallback behavior, and giving explicit integration instructions with zap_out_of_lp_position. It is complete enough for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds extra context for rpcUrl (performance implications and Alchemy key auto-extraction) and clarifies how returned parameters feed into zap_out_of_lp_position. However, owner and chainId are not expanded 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 opens with 'Maps to GET /positions. Reads all LP positions a wallet holds on a given chain', clearly identifying the verb (reads/lists), resource (LP positions), and scope (wallet+chain). It also distinguishes itself from siblings by explicitly tying its exit signal to search_liquidity_pools and instructing to call it 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?

Explicit guidance is given: 'Use this to drive exit decisions, mirroring the entry signal from search_liquidity_pools' and 'IMPORTANT: Always call this BEFORE zap_out_of_lp_position'. This tells the agent when to use it, what it pairs with, and the correct order of operations relative to another tool.

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 carries the full burden of disclosing behavior. It explains edge cases like feeAprEstimate being null outside trending mode and extrapolated/extreme on short timeframes, the semantics of momentumSignal (entry/watch/exit), and the critical caveat that 5m window signal is actually hourly context. It also warns about hookless pools and emphasizes poolId must be passed unchanged.

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 each sentence contributes actionable value. It is structured with clear sections (overview, KEY PARAMETERS, MOMENTUM SIGNAL) and front-loads the most critical (return fields, key parameters, and usage recipes) before deeper detail. The length is justified by the tool's complexity.

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

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

Given the tool has no output schema and no annotations, the description is remarkably complete. It covers all major return fields, parameter interactions, edge cases, and cross-tool integration. It even explains how suggestedRangePct feeds into zap_into_lp_position and how id vs poolId are used, leaving no important context unanswered.

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?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema. It explains how to combine signal, sortBy, sortOrder, and timeframe for actionable results, defines the behavior of feeAprEstimate relative to timeframe, clarifies the ID fields, and gives concrete examples like topPerVenue and hookless. This goes well beyond the baseline for high coverage.

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

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

The description opens with a specific verb+resource pair ('Maps to GET /pools. Discovers liquidity pools across supported AMMs and chains') and lists concrete return fields. It clearly differentiates from siblings by explicitly noting that poolId must be passed to zap_into_lp_position, id is only for analyze_pool, and list_user_lp_positions handles exit checks.

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 when-to-use guidance, including a recipe for entering ('trending: true, timeframe: "6h", signal: "entry", sortBy: "signal", sortOrder: "desc"') and directs users to list_user_lp_positions for exit checks. It also explains when to prefer 1h vs 6h timeframes and calls itself a 'Required upstream step before zap_into_lp_position'.

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 carries the full burden, and it exceeds expectations. It discloses the execution flow (approve, re-quote, send), the requirement for a private key or wallet signer, the priceImpact field requiring user confirmation, the 'swap amount too small' error case, and that quotes expire. It also notes that surplus is returned to the user. This is highly transparent behavior 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 long but well-structured with labeled sections (EXECUTION FLOW, PRICE IMPACT, ZERO OUTPUT) and uses warning symbols. It front-loads the core purpose and API mapping. The length is justified by the tool's complexity, but it contains some redundancy (e.g., 'single-transaction' repeated) and could be slightly tighter.

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

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

Given the tool's complexity (7 params, no output schema, no annotations), the description covers most essential context: supported pool types, execution prerequisites, potential errors, and safety warnings. However, it does not describe the full response structure (only mentions priceImpact and implies callData/value via instructions). This is a minor gap since the tool's output is central to its 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%, but the description adds significant meaning beyond the schema. It emphasizes that poolId must come verbatim from search_liquidity_pools and must not be modified, which is a critical constraint not fully captured in the schema. It also elaborates on tickLower/tickUpper behavior and affiliateCode's on-chain payment logic. This adds clear value over the schema alone, though the description could have covered a few more edge cases (e.g., deposits schema semantics).

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 what the tool does with a specific verb and resource: 'Builds a single-transaction zap to enter an LP position from ANY input token.' It also differentiates from the sibling tool zap_out_of_lp_position by using 'enter' vs 'exit', and describes the exact endpoint (POST /addliquidity/quote). This leaves 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?

The description provides extensive usage context: it explains that the tool works with any input token, supports both CL and classic pools, and gives explicit instructions on when to provide tickLower/tickUpper (custom range) and when to omit them (default range). It also warns about quote expiry and the need for a fresh quote before transaction. However, it does not explicitly compare to alternatives like get_swap_quote or list_user_lp_positions, so it falls short of a 5.

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 behavioral disclosure. It reveals operational traits: handles LP burn, fee collection, and swaps in one transaction; requires approvals depending on position type; quotes expire; requires a private key; and mandates presenting priceImpact to the user for confirmation. It also warns about potential reverts with 100% for classic pools. This goes far beyond a simple functional statement.

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-structured with clear headings (REQUIRED WORKFLOW, EXECUTION FLOW) and numbered steps. Every sentence adds critical information, from the API mapping to the price impact warning. No fluff or repetition—each part 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's complexity (10 parameters, no output schema), the description is remarkably complete. It covers prerequisites, step-by-step execution, approval variations, quote freshness, the price impact field, and a specific warning about classic pools. It leaves no major operational questions unanswered.

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?

Although schema coverage is 100%, the description adds significant value beyond the schema. It clarifies that positionId, nftManager, dexName, and liquidityKind come from list_user_lp_positions, explains the percent parameter's edge cases (99 vs 100 to avoid race conditions), and details how affiliateCode is forwarded. This extra context makes parameter usage unambiguous.

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 a specific verb and resource: 'Builds a single-transaction zap to exit an LP position into ANY output token.' It clearly distinguishes from sibling tools like zap_into_lp_position (entering) and list_user_lp_positions (listing positions). It also mentions the API endpoint and the ability to withdraw into any token, which removes ambiguity.

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 an explicit REQUIRED WORKFLOW: first call list_user_lp_positions, then pass the returned fields. It details the EXECUTION FLOW with approval steps, waiting for confirmation, fresh quotes, and sending the transaction. It also gives alternatives and exclusions (e.g., do NOT use approve(router, tokenId) for NFT positions, use 99% for classic pools). This fully guides when and how to use the tool.

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