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

With no annotations provided, the description carries the full behavioral burden and meets it thoroughly. It discloses the computation method (volumes via horizontal slices), the quantitative thresholds (10 mm, 0.1 L), the classification of intended geometry (wall-slab bearings, corner/T joints, objects on rugs/decks, doors in walls) into `ignores`, and the exact return shape ({conflits, ignores, elements, boite_modele}). This is unusually transparent for a geometric analysis tool.

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 a single dense paragraph, but every sentence earns its place: purpose, method, thresholds, examples, input modes, classification rules, and return shape. It front-loads the core purpose before details. It is longer than ideal but not padded; the density is justified by the tool's complexity. A slight restructuring into two short paragraphs would improve scannability, hence 4 rather than 5.

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 13 parameters, nested objects, and no output schema, the description covers everything an agent needs to call it correctly: the algorithm's rationale, the two input routes, the intended-vs-real clash distinction, and the return contract. The schema already documents each parameter's units and defaults, so the description need not repeat them. The only omissions (error handling, performance) are minor for a detection tool and not required for correct invocation.

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 100%, so the baseline is 3. The description adds genuine value beyond the schema: it points out that the scene parameters are shared with cao_generer_ifc, and it explains the `ifc` parameter's provenance ('an architect's IFC, whose GlobalIds are kept'). These clarifications help an agent reuse knowledge from a sibling tool and understand the IFC handling, going beyond the schema's literal field descriptions.

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 clear verb and resource: 'detect real clashes' in a BIM model, with explicit geometric criteria (interpenetration >10 mm and 0.1 L, computed on horizontal slices). It gives concrete examples of what is and is not caught (nested tables vs. a bed against a wall), which distinguishes it from sibling IFC tools like cao_verifier or cao_generer_ifc without naming them. The purpose is unambiguous and specific.

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 states when to use it ('WHEN coordinating a BIM model') and how to pass inputs ('Pass a scene (same as cao_generer_ifc) or `ifc`'). It clarifies the two mutually exclusive input modes and the meaning of the `ifc` text parameter. It does not explicitly list when NOT to use it or name alternatives, but the coordination context and the distinction from other cao_* tools is implied clearly enough.

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