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

Annotations only cover the safe-read profile (readOnly, non-destructive, openWorld), while the description adds rate limits (20/min, 1 per 3s), realistic timing windows (20-30 min, hours from Linea, 30+ min for EMERGENCY_WITHDRAW resolution), and the critical reassurance that EMERGENCY_WITHDRAW funds go back to the caller's own wallet rather than being lost. This is behavior an agent cannot infer from the schema or annotations.

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?

The long state enumeration is justified because each status drives a different agent action, and deprecation plus the polling rule are front-loaded. The EMERGENCY_WITHDRAW explanation is somewhat repetitive ('not to the rebalancer, not lost or stuck'), costing a little tightness.

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?

There is no output schema, so the description must carry the return-value semantics — and it does, enumerating every status with its meaning and terminality. Combined with rate limits and timing expectations, an agent has everything needed to call and interpret this tool correctly.

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?

Single parameter at 100% schema description coverage, so the schema already documents trackingId fully. The description's 'returned by submit_deposit' restates the schema text rather than adding new meaning, so the baseline 3 applies.

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 resource ('Poll the status of a deposit by trackingId') and ties the input to its producer ('returned by submit_deposit'), which cleanly separates it from get_withdrawal_status and submit_deposit. The [DEPRECATED] marker is front-loaded so an agent immediately knows the tool's standing.

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?

Gives unusually explicit when-to-stop guidance: 'keep polling' for PROCESSING but 'treat this as done, do NOT keep polling' for BRIDGING, and notes SUCCESS/FAILED are terminal. It does not name a replacement tool despite the deprecation flag, which is the one missing routing signal.

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