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

With no annotations, the description carries the full burden and does most of it well: it discloses that the server never signs or broadcasts, that the caller must supply gas, that an approve is conditionally prepended when allowance is short, and it enumerates the failure reasons (cap_exceeded, insufficient_balance, paused, not_eligible). What is missing is explicit confirmation that nothing is mutated on the server side and whether preview values can go stale before broadcast.

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?

Front-loaded with the outcome (unsigned calldata for a lend deposit) and information-dense with no filler sentences. The single run-on construction with inline code tokens and parenthetical error lists is harder to parse than it needs to be, but almost every clause carries real signal.

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?

There is no output schema, so the description must describe the return shape, and it does: `txs` ordered approve-then-deposit, plus share preview, APY estimate, and {error, reason} outcomes. Combined with the gas/keys note this is enough to invoke the tool correctly; the remaining gap is only the amount/address formatting of the two inputs.

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 0% and both parameters are bare strings, so the description must compensate. It partially does — 'account' is clarified as the owner whose key signs and whose balance is checked, and `usdg` appears inside deposit(usdg, account) — but it never clarifies whether `usdg` is a raw amount or a token identifier, nor the units/decimals or address format expected.

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?

It states a specific verb and resource (produce unsigned calldata to lend USDG into an ERC-4626 vault) and spells out what comes back: approve tx, deposit tx, share preview, APY estimate, and error codes. That is far more than a restated name, though it never names how it differs from close siblings like vault_deposit_quote or lend_withdraw_quote, leaving the agent to infer which quote tool targets which product.

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 only implied by the 'quote' framing and by the operational note 'You send every tx with the account's own owner key … this server holds no keys and sends nothing.' There is no explicit statement of when to choose this over lend_withdraw_quote, vault_deposit_quote, or lend_status, and no prerequisites or exclusions are given.

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