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

With annotations already declaring non-read-only, destructive and non-idempotent, the description still adds substantial context: sends go through the same guarded path as card validation (verified recipient, blacklist, 'Ne pas contacter', natural short delay), the call only returns a message id, and real delivery status must be read asynchronously via ficiel_statut_envoi. That is exactly the async/side-effect nuance an agent needs before firing a non-idempotent send.

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 action is front-loaded and the two sentences carry no filler; the guarded-path parenthetical is dense but informative rather than redundant. Slightly long single sentence, but each clause (path, checks, return, status lookup) earns its place.

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?

There is no output schema, and the description correctly covers the return value (message id) plus where the real outcome lives (ficiel_statut_envoi), along with the compliance checks and natural delay. It stops short of covering failure behaviour or the default when text is omitted, which are the remaining gaps for a destructive, non-idempotent send.

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 only 33% (recipient documented), so the description must compensate. It clarifies that text is optional and may be the card's text modified or not, and that the send targets 'le contact de la carte', reinforcing the recipient/card_id linkage. card_id itself is still not explicitly defined, keeping it short of a 5.

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 ('envoie le texte ... au contact de la carte') and frames itself as the widget Send button of the relance card, which sets it apart from generic sending siblings. It does not explicitly contrast with the closest neighbours (ficiel_decide_card, ficiel_prepare_followup, ficiel_send_message), so an agent must infer the boundary, but the resource and scope are unambiguous.

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 implied by 'Geste du bouton Envoyer de la carte de relance' — it is the action taken from a relance card — and it routes the agent to ficiel_statut_envoi for the outcome. There is no explicit when-not-to-use or statement of which sibling to prefer for plain outbound messaging (send_message) or for card decisions (decide_card).

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