Prepare a signable Bitcoin transaction for a RAVN DEPOSIT

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

The description explicitly discloses that it fetches UTXOs and fee rates from mempool.space, that no private key is seen or touched, and that no RAVN server is involved. This is consistent with the readOnlyHint annotation and gives an agent a clear model of the external dependency.

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 purpose is front-loaded, but the description becomes repetitive: mempool.space is mentioned twice and the 'no RAVN server involved' sentence largely duplicates the earlier privacy statement. The signer-count digression adds little operational value for a single-recipient payment.

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?

It supplies the necessary workflow context: deposit result to PSBT, then sign and broadcast yourself, with an optional fee-rate override. Since no output schema is present, a little more detail about the exact PSBT output format could improve completeness, but 'ready-to-sign PSBT' is likely sufficient for an agent.

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?

Every parameter is already covered in the JSON Schema, and the free-text description reinforces the most important mappings: toAddress is depositAddress and amountSats is depositAmount. It also adds useful constraints such as fromAddress accepting native SegWit or Taproot and feeRateSatsPerVb defaulting to mempool.space's halfHourFee.

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 names a specific action: turning a DEPOSIT-type ravn_execute result into a ready-to-sign PSBT. It gives the exact input mapping (depositAddress + depositAmount) and clearly distinguishes this preparation step from the broader quote/execute/status/health workflow.

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 clearly positions the tool as the step after ravn_execute for DEPOSIT flows and says it eliminates the need for custom UTXO selection and fee estimation. It does not explicitly enumerate cases where this tool should not be used, though none of the sibling tools appear to provide PSBT preparation.

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