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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'Lecture seule' is consistent with them. Beyond that it adds genuinely useful context: the evaluation thresholds applied (BAES >= 1 per issue and per level, 40 m horizontal path limit) and the disclaimer that results are indicative and a safety commission remains mandatory.

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?

It is front-loaded with the call trigger, then the checklist, then the scene shape, then the caveat — a sensible order with no filler. It is dense and somewhat crammed into a single sentence plus a fragment list (and only in French), which slightly hurts scanability.

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, no-output-schema check tool, the description supplies what matters: what is inspected, the pass thresholds, the expected input structure, and the authoritative-status caveat. It does not say what the response contains (e.g., per-issue violations), which is the one remaining gap.

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?

With a single nested `scene` parameter at 100% schema coverage, the schema already carries the baseline. The description still adds value by spelling out the expected sub-fields inline (ouvertures with type/fonction/signalee/encombree/x/y, pieces with nom/x/y, baes, plans_evacuation, seuil_evacuation_m?), including the optional threshold override, which clarifies how the 40 m rule can be parameterized.

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 verb and domain ('verifier l'EVACUATION d'un batiment') and enumerates the exact checks: issues signalees/pictogrammes eclaires, BAES (>=1 par issue + 1 par niveau), plan d'evacuation per level, degagement, and horizontal escape distances <=40 m. That level of specificity distinguishes it from generic neighbors like cao_bim_incendie or cao_bim_eclairage, though no sibling is named explicitly.

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 l'EVACUATION d'un batiment' gives a clear trigger condition, and the closing caveat 'Indicatif — commission de securite obligatoire' tells the agent this is a pre-check, not a regulatory verdict. No explicit exclusion of adjacent tools (signaletique, desenfumage, accessibilite), so it stops short of a 5.

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