Robinhood Chain swap builder, 0.25% disclosed fee (free)

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

Adds real behavioral context beyond annotations: output is unsigned calldata routed by KyberSwap's aggregator, a sell requires an approval sent first, and min output plus deadline are included. The annotations (readOnlyHint true, idempotent, openWorld) are consistent with a builder that returns data rather than mutating state. The only blemish is the fee framing — 'Free.' in the description versus '0.25% disclosed fee (free)' in the title, which is ambiguous rather than a contradiction.

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?

Front-loaded with the fee statement and the when-to-use rule before the mechanics, and every sentence carries information. Slightly repetitive in restating 'Robinhood Chain' and 'graduated pons token' within a single long sentence, keeping 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?

With no output schema, the description correctly carries the return-value burden: it names the unsigned transaction fields, the approval needed for sells, the minimum output and the deadline. Combined with 100% schema coverage and consistent annotations, an agent has everything needed to call and interpret the result.

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 every parameter already carries its own semantics (side default, decimals for amount, slippage bounds). The description adds only the side-specific meaning of amount, which is already in the schema, so baseline 3 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?

States the specific verb and resource: builds the UNSIGNED swap transaction for a GRADUATED pons v2 token on Robinhood Chain (chain 4663), and enumerates the returned artifacts (to, data, value, chain id). It explicitly names the sibling rhc_curve_card as the tool for tokens still on a curve, so an agent can route without opening either schema.

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?

Gives the trigger condition ('when a wallet is about to buy or sell a graduated pons token ... and needs the transaction to sign') and the explicit exclusion with an alternative ('for a token still on its curve use rhc_curve_card instead'). Nothing about when-to-use is left to inference.

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