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

With no annotations, the description carries the full burden and does so well: 'Nothing is sent: the caller signs and sends them from its own wallet within 20 minutes' discloses the side-effect-free nature, execution handoff, and time validity. It also clarifies that transactions are 'minted to the sender's wallet' and warns about price movement in shallow pools.

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?

Three dense sentences cover the output list, the no-send behavior, and a safety warning. The description is front-loaded with what the tool returns and contains no filler or repetition of schema fields that are already clear.

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 no output schema, the description enumerates the main returned items: fee, stock, ticks, weekly earnings, and the approve/open transactions. Combined with the 20-minute validity, the no-send guarantee, and the deposit warning, an agent has enough to invoke the tool correctly and interpret its results.

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 100% and the schema already explains pool, usdg, and range_pct, so the baseline is 3. The description adds useful context beyond the schema by linking usdg to the 1% fee, framing range_pct as a range 'around the current price,' and warning that deposit size matters in shallow pools.

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 title says 'Quote a position and build the transactions that open it,' and the description expands with a concrete verb-resource pair: it returns a fee, stock amount, ticks, weekly earnings, and transactions. It is clearly distinct from sibling tools like list_pools, get_pool, book_status, and my_positions because it both quotes and constructs transactions rather than listing or inspecting pools.

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 opening 'For an amount of USDG and a range around the current price in one of LoomDesk's own pools' provides clear context for when to call it. It also gives practical guidance like 'Keep a deposit under maxSensibleDepositUsdg' and warns about shallow-pool price impact, though it does not explicitly name alternative tools or exclusions.

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