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

Annotations already declare readOnlyHint and openWorldHint, so the safety baseline is covered. The description adds real value beyond that: non-custodial, quote-only, and that it filters unsafe routes and ranks alternatives. It stops short of describing return format or any rate-limit behavior, but with no output schema the ranking claim is a useful behavioral signal.

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?

A single front-loaded sentence with no filler; the scope and the 'quote only' caveat arrive first. It is dense rather than bloated, though the final 'non-custodial' could arguably be folded earlier.

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 an 11-parameter, nested-object, read-only quoting tool with no output schema, the description covers what the tool does, which chains/providers it touches, and that it ranks results with alternatives. The main gap is that the nested constraints object and the shape of the returned quote are not described anywhere.

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 coverage is 73% and the schema documents most parameters well, including the amount decimals rule and chain keys. The description only adds that providers are LI.FI/Across and which chains are supported; it says nothing about the nested constraints object (max_slippage_bps, require_executable, max_value_loss_bps), which the schema also under-documents. Baseline 3 is appropriate.

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 resource (cross-chain bridge route quotes) and concrete actions: compares LI.FI and Across, computes net received value in USD, filters unsafe routes, ranks the best. Named chains and providers make the scope unambiguous. No siblings exist, so no differentiation is needed, but the sentence is heavy with multiple verbs.

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?

'Quote only, non-custodial' clearly bounds usage: this returns a quote and does not execute the bridge, which is the key when-not guidance. It does not state prerequisites (e.g., that a sender address improves accuracy) or what to do after receiving a quote, and there are no sibling tools to route against.

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