build_sell_tx

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

With no annotations, the description carries the full burden. It usefully discloses that the output is an unsigned transaction and that selling happens back to the curve with a whole-token amount, but it omits permissions, approval requirements, slippage behavior, and what v1/v2 means.

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 short, front-loaded, and free of filler. However, the trailing 'v1 or v2' is cryptic and does not clearly earn its place without further explanation.

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 transaction-building tool with zero annotation coverage, 0% schema description coverage, and three parameters, the description is too thin. It lacks token format, slippage semantics, version behavior, and any relation to quote_sell or approval flows.

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 0%, so the description must compensate. It clarifies that 'amount' is a whole-token amount, which is valuable, but it says nothing about the 'token' parameter format (e.g., mint address) or the optional 'slippagePct' parameter.

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 action and resource: build an unsigned transaction to sell AgentPad tokens back to the curve. It implicitly distinguishes this from buy tools by naming the sell direction, but it does not explicitly distinguish itself from siblings such as quote_sell.

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?

There is no guidance on when to use this versus quote_sell, agentpad_buy, or other build_* transaction tools. The phrase 'v1 or v2' is not explained, and no prerequisites or exclusions are given.

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