cao_generer_ifc

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

No annotations exist, so the description carries the full burden and delivers: output format (IFC4), structural content (project/site/building/storeys hierarchy, IFC GUIDs, material density/thermal conductivity), a documented limitation (no boolean opening cut in the host wall), and a precondition (cao_verifier first). Disclosing the missing opening is exactly the kind of behavioral trait that prevents agent disappointment.

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?

Five sentences and roughly 100 words, with the most decision-relevant information front-loaded in the opening WHEN clause. No filler — each sentence contributes a distinct fact: trigger condition, output content, limitation, prerequisite, and sibling anchor.

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 10-parameter, no-annotation, no-output-schema tool, the description covers output content, the documented limitation, and the precondition. The main gap: it never states how the IFC file is delivered (file path, download, inline content?), which an agent needs to complete the workflow. It also leaves implicit which scene subsets (toitures, plomberie, decoration) are honored in IFC output, though the 'same scene' statement mitigates this.

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% — all 10 parameters have descriptions — so the baseline is 3. The description adds value above that: 'Same scene as cao_generer_dxf' lets an agent reuse knowledge of the sibling's scene structure, and it clarifies that ouvertures, though labeled 'used only by cao_pdf' in the schema, do produce IfcDoor/IfcWindow elements in this tool.

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+resource: 'get an IFC4 file' with real spatial hierarchy, per-element IFC GUIDs, and materials carrying physical properties. It distinguishes from siblings with 'not just a drawing' and anchors itself against the closest sibling via 'Same scene as cao_generer_dxf.' An agent navigating 40 sibling tools can tell exactly what this tool produces.

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?

Opens with an explicit WHEN trigger — 'drawing must leave as a real BIM file, openable in Revit/ArchiCAD/Solibri' — and contrasts it with 'not just a drawing.' It names the alternative (cao_generer_dxf) and gives a mandatory prerequisite: 'Call cao_verifier first.' Explicit when-to-use plus a sequencing rule.

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