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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the description's key contribution is that it returns *unsigned* transactions the wallet must sign, which is critical behavioral context not in the annotations or schema. It also explains the economic effect (earns lending fees/interest) and the side effect of post:true (collateral enabling borrowing). It does not mention ordering of returned transactions or approval requirements.

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, no filler, with the asset choice stated first and the post flag second. Every clause carries information an agent needs.

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 4-param prepare/build tool with no output schema, the description covers the asset duality, the post shortcut, and the unsigned-transaction nature. Remaining gaps (approval flows, whether the txs must be submitted in order, fee accrual details) are secondary but would matter for a full workflow.

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 100%, so baseline is 3; the description exceeds that by explaining *why* post exists ('lent and posted in one step so USDG can be borrowed against it') and by framing 'asset' as either USDG or a stock symbol with different downstream behavior. Amount formatting and wallet signing are left to the schema.

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 concrete payload ('unsigned transactions') and two distinct modes: lending a stock to shorters for fees, or supplying USDG to the Borro USDG vault for interest. This is specific and distinct from borrow/repay siblings, though it never names an adjacent tool to sharpen the boundary.

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?

Implied usage is clear enough (earn fees/interest, or enable borrowing via post:true), and the post case is conditioned explicitly. However there is no when-not guidance, no statement of required prerequisites (e.g. token approval, sufficient balance), and no comparison to the obvious alternative 'borrow' beyond a passing mention.

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