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

With no annotations, the description carries full behavioral burden and succeeds. It discloses the operation is side-effect-free ('Nothing is signed or submitted'), notes simulation is conditional ('simulate it where supported'), and reveals the return contract implicitly via 'previewHash'. This exceeds typical transparency and provides safety guarantees an agent needs.

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 sentences, each purposeful: first defines action and inputs, second enforces safety, third instructs downstream workflow. Front-loaded with the tool's identity ('Pre-sign preview') and zero filler. Every clause adds critical nuance without bloat.

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?

For a preview tool with no output schema, it covers the essential flow, return key (previewHash), and human-in-the-loop requirement. Missing details like error cases or edge conditions when simulation isn't supported, but the core workflow is fully specified. Given the multi-chain complexity and lack of annotations, this is strong but not perfect.

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 covers 67% of params with executionId and portal described. Description mentions 'pending plan' and 'provisioned Turnkey wallet,' which adds minimal disambiguation, and references the prior ava_copilot_turn step for executionId. However, it does not clarify userId or explain parameter relationships beyond the flow. Adequate but does not fully compensate for the missing schema description.

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?

Uses specific verbs and resources: 'build the exact venue artifact... return it UNSIGNED' and names concrete artifact types (CoW EIP-712 order or unsigned Solana transaction). Clearly distinguishes itself from sibling ava_approve_execute by framing itself as the pre-sign step. No ambiguity about what tool does.

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 states when to use: 'Pre-sign preview' and provides sequencing ('pass the returned previewHash to ava_approve_execute'). Sets boundaries with 'Nothing is signed or submitted,' and indicates the when-not-to-use by routing the actual signing to a sibling. Gives clear user responsibility ('Show the artifact to the human').

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