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

With no annotations, the description carries the full burden and does substantial work: it discloses the approval 0.1% headroom rationale, the no-dust 'all' path, post-action HF/LTV in the response, the error-answer set, oracle independence, and that this server never signs or sends. It stops short of describing the exact returned object (to/value/gas) or any rate or gas constraints.

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?

Purpose is front-loaded in the first clause and every sentence carries real information about calldata shape, approvals, or outcomes. It is dense and parenthetical-heavy, which makes the 'when short' and approval-headroom clauses harder to parse than necessary.

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?

No output schema exists, so the description must fully describe the return value; it names HF/LTV and the error answers but not the actual payload fields (calldata, target address, whether approve and repay are one or two transactions). For a 3-parameter calldata-builder this leaves an agent guessing about the response shape.

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 must compensate. It explains the 'usdg' parameter well (amount vs 'all' semantics with no dust) and ties 'account' to the owner key, but the 'market' parameter and its null default are never explained, leaving one of three parameters undocumented in both schema and description.

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 the specific verb and resource up front: 'The unsigned calldata to repay USDG debt', followed by exactly what the calldata contains (approve + repay call shape). An agent can immediately tell this apart from the other borrow_* quote and status siblings.

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?

Usage is implied by the action name and by the enumerated terminal answers (nothing_to_repay, exceeds_debt, insufficient_balance), plus the note that the caller must send it with the owner key. However, it never says when to reach for this instead of borrow_status or how to sequence a status check before quoting.

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