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

With no annotations provided, the description carries the full behavioral burden. It discloses return contents (winning quote, all venue quotes, fee recipient) and cross-chain support, which is useful. However, it doesn't explicitly state that this is a read-only operation (no swap execution) or mention any side effects, rate limits, or auth requirements. The lack of a clear 'does not execute' statement leaves room for misinterpretation.

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 sentences with no fluff. The purpose is front-loaded, and the additional details (transparency of venue quotes, fee recipient auditability, cross-chain support) are concise and relevant. Every sentence earns its place.

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 tool with nested objects, 4 parameters, and no output schema, the description is reasonably complete on return behavior but lacks parameter guidance and limitations. It mentions cross-chain on EVM but doesn't clarify single-chain usage or how to specify chains/addresses. It also doesn't mention potential errors or constraints. There are gaps that an agent would need to infer or probe.

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 50%, so the description should compensate for undocumented parameters. It does not mention any parameters at all – sell, buy, amount, or slippageBps. The schema provides some description for amount and slippageBps, but the nested sell/buy objects lack top-level descriptions. The description adds zero value on how to structure inputs, leaving the agent to rely on the schema alone.

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 clear verb ('Get') and resource ('best swap route across DEX aggregator venues') and adds specific return details (winning venue quote, all quotes, fee recipient). It doesn't explicitly name sibling alternatives, but the scope is distinct enough to separate it from build_swap_transaction or plan_route.

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 description implies use for obtaining quotes before building a transaction, and mentions cross-chain support as a capability, but it never states when to choose this over siblings or any exclusions. There's no explicit when-not guidance, so the agent must infer usage from the tool name and context.

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