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

With no annotations, the description carries the full burden, and it does disclose two important traits: the transaction is unsigned (the agent must sign/broadcast) and an ERC-20 approval tx may be appended. It does not say whether the approval is exact-amount or unlimited, whether calldata must be sent to a specific contract, or whether any state is mutated server-side.

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 short sentences, zero filler, and the core capability plus the notable side effect (approval tx) are both front-loaded.

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?

The tool builds and returns transaction payloads with an output schema and no annotations, on 7 parameters with near-zero schema documentation. The description leaves the most failure-prone details (amount units, token identifier format, default recipient, slippage semantics) unaddressed, so an agent can call it correctly only by guessing.

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 only 14% (only `sender` is documented) across 7 parameters, so the description must compensate and does not. Critical ambiguities remain: is `amount` human-readable or base units, are tokenIn/tokenOut addresses or symbols, what happens if `recipient` is omitted, and what slippageBps=50 means in practice.

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?

Specific verb+resource: 'Build an unsigned Velora Augustus v6.2 swap tx plus ERC-20 approval tx if needed.' The protocol name and version distinguish it from velora_quote and from the other *_build_tx siblings at a glance. It stops short of explicitly saying which sibling to pick when several aggregators are available, but the resource is 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?

'Same fee as velora_quote' implies the quote-then-build pairing, and 'if needed' signals the approval tx is conditional, so usage is inferable. However, there is no explicit statement that velora_quote should be called first, no guidance on when to prefer this over swap_build_tx or zerox_build_tx, and no prerequisites (allowance state, signing wallet) spelled out.

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