prepare_transactions_utxo

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the output is unsigned (not broadcast), that it returns fee details, the required fee inputs, and a credit cost (530). It omits auth/credential requirements, rate limits, and what the fee model does when neither strategy applies – gaps that matter on a 12-param mutation-adjacent builder.

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-loads purpose, then the sign/broadcast workflow, then action details, then credits. The credits boilerplate ('indicative only, may change') is partly filler but is bounded and clearly separated. Overall well-structured with minimal waste.

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?

With 12 params, no output schema, and no annotations, the description does substantial lifting: it explains the returned unsigned tx + fees, the action set, the fee requirement, and the follow-on tools. It is nearly complete, though it could state auth/prerequisite context given the parameter weight.

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 every parameter (action enum, feePriority/exactFee, recipients, fromAddress, locktime, etc.) is already documented in the schema. The description largely restates this by naming the single action and its fee constraint, adding little syntax or format detail beyond the schema. Baseline 3 applies.

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 + resource (build unsigned UTXO transactions) and enumerates the exact chains (Bitcoin, Bitcoin Cash, Litecoin, Dogecoin, Dash, Zcash). This cleanly distinguishes it from the sibling prepare_transactions_evm/tron/solana/etc. that target other ecosystems. An agent can route without opening any other definition.

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?

Explicitly lays out the downstream workflow: sign locally with utxo_sign, then broadcast via broadcast_signed_transaction, and notes the feePriority-or-exactFee requirement. It does not explicitly say when to prefer this over sibling chain tools, but the chain enumeration and workflow cover the practical selection decision.

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