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

Annotations already declare destructive=true, openWorld=true and idempotent=true; the description adds the operationally critical context of cost ('costs the approved total') and irreversibility ('cannot be undone after printing starts'). The stated refusal of a second send and of changed batch/price is consistent with idempotentHint and gives the agent a clear recovery path.

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?

Dense and front-loaded: purpose, cost, irreversibility, preconditions, then instructions. A few phrases are cryptically terse ('ORDER_REQUIRED: give the user the order_url'), and 'Refuses... a second send' partially duplicates 'Do not call send_card again'.

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 destructive, money-spending action this covers preconditions, refusal behavior, the confirmation handshake, and the follow-up requirement to surface order_url. With an output schema available and full schema coverage, nothing essential is missing.

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 the schema already defines every parameter including the conditional distinct_messages rule and allow_duplicate. The description mostly restates which values to pass ('Give batch_id, batch_sha256, confirmed_count...') rather than adding new meaning, so the 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 and resource ('mails the greeting cards of a batch') and anchors it to a named sibling ('from prepare_card'), so an agent can tell it apart from prepare_card and the letter tools. The irreversible-after-printing scope is stated in the same opening block.

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?

Gives explicit preconditions ('only after the user approved the picture, the message, each recipient and the total price, in a later answer than prepare_card'), explicit refusal cases, and an explicit terminal instruction ('Do not call send_card again'). Nothing is left to inference about when this tool should fire.

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