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

Annotations already establish that the tool is read-only, non-destructive, and closed-world, but the description adds important behavior: authentication may be requested on first use, the possible status outcomes are enumerated, and agents are warned not to report success prematurely. This is material operational context beyond the 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?

The description is three focused sentences: authentication context, status semantics, and a critical usage warning. It is front-loaded and every sentence contributes useful information.

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 one-parameter read-only status tool with no output schema, the description is complete enough: it identifies the caller context, enumerates the possible outcomes, and supplies the key rule for interpreting the result before telling the user the operation succeeded.

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%, and the schema already explains that the single parameter is the returned reference such as D123. The description adds some contextual meaning by tying it to a prepared request, but it does not add syntax or format details beyond the schema.

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 states a specific verb and resource: it tells whether a prepared request has been confirmed/done, refused, failed, or is still pending. The examples of prepared requests (envoyer_argent, retirer_mobile_money, deplacer_argent) make clear which family of operations this status check applies to.

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?

It specifies the usage context: the connected Tchin user, merchant or individual, with first-time authentication. It also gives a strong sequencing rule not to tell the user something is done until this tool answers 'fait', though it does not explicitly name alternatives such as etat_paiement or detail_transaction.

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