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

readOnlyHint=true already declares the safety profile, and the description is consistent with it by framing the tool as preparation rather than execution. It adds genuinely useful context beyond the annotations: that no preflight validation of collateral, delegation, health factor, caps, or liquidity occurs, putting that burden on the caller. It does not say what the prepared output looks like or whether approvals must exist first.

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?

Two sentences, zero filler, with the capability stated first and the limitation second. Every clause carries information an agent would otherwise have to guess.

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?

An output schema exists, so return values need no explanation, and all five parameters are documented. The remaining gap is that the description does not state prerequisites such as token approval or where the market/asset list comes from, but the core call semantics are complete.

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 the baseline is 3. The description reinforces the 'supported fixed reserve' constraint on asset and mentions on-behalf-of credit delegation, but adds no syntax or format detail beyond what each parameter's schema description already provides.

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 (prepare), a specific protocol action (Aave V3 variable-rate borrow), and the reserve constraint (supported fixed reserve). The optional on-behalf-of credit delegation is called out, which distinguishes it from the sibling prepare_aave_v3_supply/repay/withdraw tools.

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?

The second sentence gives a clear negative scope: the tool does not check collateral, delegation, health factor, caps, or liquidity, which tells the agent this is a blind transaction builder rather than a validated one. It does not name a sibling or prerequisite tool (e.g. get_aave_v3_markets) to satisfy those checks, so it stops short of full routing guidance.

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