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

While annotations carry destructiveHint=true and readOnlyHint=false, the description adds substantial behavioral depth on top: timeout semantics (backend may accept but response may lag), idempotent retry safety ('it cannot double-spend'), the 409 signature-already-used semantics confirming prior success, the Linea Aave USDC funding-cap refill conflict, and rate-limit rules (20 calls/min, 3s spacing). No contradiction with 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 description is long, but every sentence carries operational value — this is a mutation tool with many failure modes, so the density is justified. Front-loading is strong: purpose first, prerequisites second, then errors. The timeout/error paragraph is a nested wall-of-text that could be restructured into clearer conditional braches, and the rate-limit info is buried at the end, which slightly hurts scannability.

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 high-complexity tool with 8 required params, no output schema, and significant failure modes, the description covers prerequisites, sequencing, all error paths (403, two distinct 409 cases, timeout), recovery procedures with the trackingId, and rate limits. Nothing an agent needs to call it correctly or recover from a timeout is missing. The absence of output schema is compensated by the detailed trackingId recovery guidance.

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 88%, so the baseline is 3. The description adds genuine meaning beyond the schema: the signature's EIP-712 domain is scoped to the provided chain (smart-contract wallet implications via ERC-6492 vs EOA), the jwt↔walletAddress binding is reinforced by the 403 error semantics, and the replay-safety of reusing the same signature. poolContract remains covered only by its regex pattern, but that is a minor gap against the strong 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?

The first sentence states a specific verb ('Submit'), resource ('withdrawal from MetaLend's rebalancer'), and effect ('moves funds'). It is clearly distinguished from siblings: prepare_withdrawal is called first (this tool 'does not look up pool data or validate amounts'), and get_withdrawal_status is referenced for tracking. An agent can tell this from the prepare/get siblings immediately.

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 explicit when-to-use guidance: 'Always call prepare_withdrawal first' and prerequisite requirements for jwt and signature. It also specifies when NOT to escalate (read trackingId from the 409 error and call get_withdrawal_status directly) versus when to escalate (timeout without trackingId), plus explicit error-code handling for 403 and 409 cases. This is far beyond a typical tool description.

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