Build an unsigned Indigo open-CDP transaction

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

Annotations provide only readOnlyHint=false, openWorldHint=true, and destructiveHint=false. The description adds substantial behavioral disclosure: the server never signs, never submits, never holds keys or funds, the returned tx is unsigned and must be signed by the agent, and Pyth-priced txs expire and fail on-chain if stale. No contradiction with annotations.

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?

Four dense sentences, each earning its place: the first states the main purpose and return value, the second covers the critical timing caveat, the third clarifies the security/trust model, and the fourth lists prerequisites. There is no filler or redundancy.

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?

Despite having no output schema, the description fully specifies what the agent receives, what to do next, what can fail, and what environment prerequisites are needed. It covers return format, signing/submission workflow, expiry behavior, collateral type, and required configuration, making the tool safe and actionable.

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 all four parameters are already documented with units and formats. The description reinforces that ADA collateral is used and gives 'iUSD' as an example iAsset, but it does not meaningfully extend parameter semantics beyond the schema. Baseline 3 is appropriate.

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 verb ('build') and resource ('transaction that opens an Indigo CDP'), with concrete actions ('lock ADA collateral and mint an iAsset') and the precise return type ('UNSIGNED transaction as CBOR hex with an empty witness set, plus a human-readable summary'). This clearly distinguishes it from sibling tools like close_cdp and build_swap_tx.

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?

The description gives clear context for use: it is for opening a CDP and the caller must sign and submit the result. It also provides a critical timing guideline with the ~280-second price-validity window and instructs to rebuild if the tx goes stale. It does not explicitly name sibling alternatives, but the usage context is unambiguous.

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