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

With no annotations the description must carry the behavioral burden, and it largely does: it discloses that only unsigned calldata is returned (the server never sends), enumerates refusal reasons (unhealthy, oracle_stale, insufficient_collateral), and explains oracle fail-closed semantics including the no-debt bypass. What remains underspecified is the exact return shape and how HF/LTV and the 70%-of-LLTV warning are emitted.

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 core action is front-loaded in the opening clause, and the subsequent refusal and warning details earn their place. The single long sentence stacking multiple refusal reasons is dense but not padded.

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 quote tool with no output schema, no annotations, and 0% parameter coverage, the description covers refusal behavior and oracle edge cases well but leaves the return payload structure and key parameter defaults unaddressed. An agent could invoke it but may not fully anticipate the response or the 'all' shares default.

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 0%, so the description is the only source of parameter meaning. It partially compensates by spelling out the withdrawCollateral signature (marketParams, shares, account, account), but this maps awkwardly onto the three schema params and leaves the 'shares' default of 'all' and the optional 'market' (default null) unexplained, risking confusion.

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 specific verb and resource: unsigned calldata for withdrawCollateral that takes fund shares back from Blue, naming the exact contract function and its arguments. It is clearly distinct from supply/repay siblings. It stops short of an explicit routing statement but the action is unambiguous.

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?

It gives useful workflow context ('You send it with the account's own owner key; this server never sends') and lists refusal conditions, which implicitly tells the agent when the call succeeds. However, it never states when to use this versus siblings like borrow_supply_collateral_quote or close_quote.

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