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

The description offers substantial behavioral detail beyond the annotations: links expire after 48 hours, are non-recoverable, and each new call invalidates previous unused links. It also discloses the automatic email dispatch on final signature. This aligns with destructiveHint=true and provides critical side-effect information an agent needs to handle the tool correctly.

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 sentences, starts with the main action, and each sentence adds distinct value: the purpose, the legal importance and automatic email, and the link validity/invalidation behavior. No filler or redundancy.

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 tool with no output schema and moderate complexity, the description covers the core behavior, side effects, and important constraints. It does not mention error cases or the exact return format, but the provided context on signature requirements and link management is sufficient for most invocation scenarios. Sibling tools and schema descriptions fill remaining 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?

Input schema coverage is 100%, with detailed descriptions for all parameters. The tool description does not add new parameter-level semantics; it only gives broader context about signatures and link validity. According to the rubric, baseline 3 is appropriate when the schema handles parameter documentation, and the description adds no extra parameter-specific value.

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 opens with a specific verb and resource: 'Émet les liens de signature à transmettre aux conducteurs' (emits signature links to transmit to drivers). This clearly defines the tool's function and distinguishes it from sibling constat tools that handle other steps like renseigner, finaliser, or annuler. The legal context reinforces the purpose: the constat only has legal value with both signatures.

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?

The description implies when to use the tool: after the constat has been prepared, to collect signatures. It notes that the email sends automatically upon the last signature, which frames the expected workflow. It also warns that links are valid for 48h and a new call invalidates previous unused links, which guides repeated use. No explicit alternative tool is named, but the tool family context makes the usage context clear.

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