Purge RGPD des candidats inactifs

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

Annotations already declare readOnly/idempotent/non-destructive; the description goes further by stating it calls no BoondManager API, reads no data, and generates the response server-side. The line 'rien n'est fait par cet appel' and 'jamais en lot silencieux' add important behavioral 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 well-organized with 'Quand', 'Plutôt que', and 'Returns' sections, and each sentence contributes either usage guidance or behavioral clarity. It is a bit long and the opening scenario sentence could be tightened to avoid the false impression of direct deletion, but the structure compensates.

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 workflow runbook with no output schema, the description explains the return value (ordered list of Boond calls with exact filters) and that the model must execute them. It also covers the no-API, no-data-read behavior and the prompt alternative, so an agent has enough to decide and invoke correctly. The only remaining gap is clarifying that the 'confirmation list' is part of the runbook, not an interactive UI.

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 both parameters have descriptive help text, so the description need not repeat them. The description indirectly references the N-month inactivity concept but adds no extra detail about manager_id or mois_inactivite beyond the schema. Baseline 3 is appropriate.

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 concrete workflow: identify inactive candidates, propose a confirmation list, and delete individually, while the Returns line clarifies the tool actually produces a runbook rather than executing the deletion. It distinguishes itself from the MCP prompt variant and from direct mutation tools by stating no API is called. The opening sentence still reads as if the tool performs deletions, creating mild ambiguity.

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?

Explicit 'Quand' states it is for running a multi-step scenario without finding the tool chain and filter names manually. 'Plutôt que' names the exact alternative (prompt purge_rgpd_candidats) and the condition for choosing this tool (clients that mishandle prompts/get). This is strong route-selection guidance.

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