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

Annotations already establish readOnly, idempotent, non-destructive, and closed-world behavior, so the bar is lower. The description still adds real context beyond them: the order must be paid, and the caller must supply the email used for payment, which functions as an identity/verification requirement. It does not say what happens for unpaid or not-found orders.

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?

A single efficient sentence with the key qualifier ('commande payée') and both parameter hints front-loaded. No filler, though the phrasing is slightly dense and could separate the verification constraint from the format example.

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 no output schema and no parameter descriptions, the description should say more about the returned stage representation (text status, codes, timestamps) and error behavior on mismatch of email or unpaid orders. For a simple read-only lookup it is adequate but leaves clear gaps.

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 0%, so the description carries the full burden. It documents both parameters meaningfully: order_number carries the MM-XXXXXX format, and email is specifically the address used to pay, implying a must-match constraint. It stops short of stating case sensitivity or format validation rules.

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 resource and outcome: the manufacturing and delivery stage of a paid order, retrieved via order number and payer email. It is clearly distinguishable from create_design or list_products, but it never explicitly contrasts with get_group_status, the closest sibling for the group-order variant.

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?

Usage is only implied: the phrase 'commande payée' signals this applies to individual paid orders, which implicitly excludes quotes, designs, and group orders. No explicit when-to-use statement or routing to get_group_status for the group case is given.

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