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

Annotations already declare readOnly/destructive=false, and 'Lecture seule' merely restates that. The genuine added value is the 'Indicatif — carnet sanitaire et bureau de controle priment' disclaimer, which tells the agent the verdict is advisory rather than a compliance ruling, plus the regulatory basis (arrete qualite de l'eau). Nothing is said about the returned result format, which is a modest gap.

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 trigger condition is front-loaded and each clause carries a distinct rule or caveat. It is dense but not padded; the only mild redundancy is restating the eau_froide object shape already present in the schema.

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 read-only, single-parameter, no-output-schema check, the description covers trigger, rules applied, input shape, authority caveat and read-only nature. The only missing piece is what the result looks like (per-item conformity findings vs. a single verdict), which the agent must discover by calling.

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%, so the baseline is 3, but the description earns more by giving the semantic rules behind the nested fields: temperature_distribution_c is judged against the 25 C limit, isole is judged relative to nearby ECS (hot water) sleeves, and materiau against an allowed list with lead forbidden. That explains what each sub-field means for the check, not just its shape.

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 (verifier) and a precisely scoped resource (reseau d'eau froide sanitaire) and enumerates the four checks performed: distribution temperature <= 25 C, insulation of adjacent DHW sleeves, frost protection, and permitted materials with lead prohibited. It never names a contrasting sibling (e.g. cao_bim_eau, cao_bim_legionelles), so an agent must infer the boundary from domain wording alone.

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?

'Appelez quand vous devez verifier le RESEAU D'EAU FROIDE SANITAIRE' gives an explicit call trigger, and the closing caveat that the carnet sanitaire and control bureau take precedence clarifies the tool's role. There is no statement of when NOT to use it or which sibling handles hot water / legionella checks instead.

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