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

Annotations already declare readOnlyHint=true/destructiveHint=false, and the description reinforces 'Read-only'. It adds genuinely useful behavior beyond the annotations: that orderType must be passed for a resting order so the correct fee cell is served, that feeLegs are what a signed order must embed, and that amounts are RAW token units. It does not explain the idempotentHint=false asymmetry or any rate limits.

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-loads the payload contents, then routes to alternatives, then states read-only and unit conventions. Every clause carries information; no filler.

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 compensates by naming the returned fields (venue split, expected/minimum output, price impact ppm, feeLegs) and the unit convention. For a 7-parameter routing tool it is nearly complete; only the idempotency flag and response shape specifics are left to inference.

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 including wallet, orderType, triggered and slippageBps is already documented in the schema. The description restates the orderType/fee-cell dependency and the RAW-unit convention rather than adding new syntax or format detail, which lands at the baseline for full schema coverage.

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 (get) and resource (route) and enumerates exactly what the breakdown contains: venue split, expected/minimum output, price impact in ppm, and feeLegs. It explicitly contrasts with get_quote ('plain price') and check_order, so an agent can distinguish it from siblings without opening schemas.

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?

Names two alternatives with the condition that selects each: get_quote for a plain price, check_order for executability of a resting order. It also states when to pass orderType (resting order) versus omit it (direct swap), covering both when-to-use and when-not-to-use.

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