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

Annotations only say non-read-only, idempotent, non-destructive; the description adds much more: no message is sent, the card is editable and awaits approval, an existing pending card is returned as-is without a new draft (matching idempotentHint), refusals occur before any AI call, cost is one conversation of the monthly quota, and the « write » scope is required.

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 most decision-critical fact (N'ENVOIE RIEN, plus the approval path) is front-loaded and the cost/scope line closes cleanly. The opening capslock parenthetical about the screen and the long refusal enumeration are dense, but each clause carries operational weight rather than filler.

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 two-parameter, no-output-schema tool this is essentially complete: side effects (none sent), idempotent behavior on an existing card, preconditions, refusal taxonomy, quota cost, and required auth scope are all covered. An agent can call it correctly and interpret the result without further context.

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 recipient property already documents the mandatory check, accent/case tolerance, the « sans nom » escape hatch and the recipient_mismatch refusal. The description only restates that recipient is mandatory and verified against the real contact before any generation, so it adds emphasis but little new semantics – 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?

The description names the exact operation (draft ONE follow-up message for a conversation via Kord, then surface it as an editable card) and anchors it to a concrete UI equivalent (« le bouton Préparer de la liste À relancer »). It is unambiguously separable from ficiel_envoyer_relance and ficiel_carte_relance because it states up front that nothing is sent and the card is what gets produced.

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 gives the when (a conversation needs a follow-up drafted), the when-not (all the refusal cases: blacklist, excluded tag/stage, Kord disabled or at rest, already contacted today, automation running, channel disconnected, group), and the explicit next step (approve via ficiel_approve_card or in Ficiel). No inference is left to the agent about sequencing.

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