Build unsigned Comfy swap

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

Adds real behavior beyond the annotations: sells emit conditional ERC20→Permit2 and Permit2→router approval transactions in order, the recipient receives output while the signing wallet supplies input, and nothing is signed or broadcast. This matters because readOnlyHint=true is otherwise ambiguous for a tool that assembles transactions. Minor gap: no statement on quote expiry/freshness or failure modes.

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?

Four short sentences, front-loaded with the core purpose and the UNSIGNED/no-keys constraint, then the sell-approval ordering. No filler, no repetition of the title.

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 5-required-parameter builder with no output schema, the description covers the essential contract (unsigned, per-role semantics, approval chaining). It only partially conveys the return shape — it implies an ordered list of transactions but never says so explicitly, leaving an agent to guess whether output is one tx or many.

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?

With only 20% schema description coverage the description needed to carry parameter meaning, and it does clarify the recipient-vs-signer distinction. But it also says 'Values are decimal wei strings,' while the schema's `amount` is documented as 'Exact decimal human units ... No exponents' — a direct and dangerous contradiction on the most error-prone parameter. `slippage_bps`, `token`, and `side` receive no added 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?

States a specific verb and artifact: 'Build an UNSIGNED ComfyRouter transaction from a fresh quote.' This clearly separates it from comfy_swap_quote (which presumably produces the quote) and from comfy_build_launch_tx (a different transaction builder). An agent can select it without opening the 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?

'From a fresh quote' implies the prerequisite step in the comfy_swap_quote → build → sign workflow, and 'No keys, signatures or transaction submission' marks the handoff point after this tool. However, no sibling is named explicitly as an alternative and there is no statement about when this tool should not be used (e.g. stale quotes).

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