pons_quote_swap

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

With no annotations, the description carries the behavioral burden and does add useful facts: it is on-chain via V4Quoter, includes hook fees, supports both native-ETH and ERC-20 quoted pools, and returns amountOut, gas estimate, pool key, and price/liquidity state. It does not explicitly state that quoting is read-only or describe error/failure behavior, so it falls short of fully transparent.

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 compact and front-loaded, with the core action and scope in the first sentence. The output list is dense and informative, though the compressed notation 'sqrtPrice/tick/liquidity' and the fragment-style second sentence keep it from being perfectly polished.

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 annotations and no output schema, the description supplies most necessary context: the quoting mechanism, fee behavior, supported pool types, and the returned values. The main missing pieces are explicit guidance for choosing between sibling quote tools and a fuller description of return-value format, but an agent can still invoke the tool correctly using the schema.

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% and the schema already documents the nuanced side/amount semantics, including the buy/sell distinction and pair-token versus ETH units. The tool description reinforces the existence of native-ETH and ERC-20 pools but adds no new parameter-level detail beyond the schema, so the baseline 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 action ('Quote a Uniswap V4 swap') and the exact resource scope ('GRADUATED token', 'on-chain V4Quoter', 'hook fees included'). It also enumerates the returned fields, giving it stronger identity than a generic quote tool. It does not explicitly name sibling tools, but its specificity is enough to distinguish it from vague alternatives.

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 phrase 'for a GRADUATED token' implies the tool is meant for post-graduation pools, and 'Native ETH-quoted and ERC-20-quoted pools' clarifies the pool types it supports. However, it never explicitly says when to use this tool instead of pons_quote_buy or pons_quote_sell, leaving sibling selection to inference.

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