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 cost and side-effect risk ("FREE, no API key, 0 units"), return type ("this returns JSON, the drawing comes from the next call"), result guarantees ("ALREADY-VERIFIED... zero audit alerts"), and units ("All dimensions are MILLIMETRES"). The phrase "hands back" implies a non-destructive read operation, so the safety profile is clear without annotations.

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 organized into labeled sections (WHEN / WHY IT MATTERS / GOOD CALL / DO NOT) and front-loads the trigger condition and primary action before any justification. It is longer than average and the ALL-CAPS styling is visually noisy, but nearly every section carries decision-relevant information — the WHY IT MATTERS failure-mode examples ("openings.z used as an absolute altitude instead of a relative sill") earn their place by reinforcing why the tool should be tried first.

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 one optional parameter, no annotations, and no output schema, this description covers the essentials: return type, invocation variants, exclusions, units, cost, and the complete downstream workflow. The main gap is that it never outlines the structure of the returned `scene` object, but since the description explicitly chains the output into cao_verifier and the CAD generators, an agent has enough context to invoke and route the result correctly.

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% for the single `exemple` parameter, setting the baseline at 3. The description adds real increments beyond the schema: explicit invocation syntax including the default ("cao_demo {} -> the house"), worked examples for each enum value ("cao_demo {"exemple": "appartement"} for a flat with no roof"), and a mapping from option to scene outcome. This is modest but genuine added value over the already-rich schema 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 states a specific action and deliverable: "It hands back a COMPLETE, ALREADY-VERIFIED scene (zero audit alerts) plus the exact next calls in order." It actively distinguishes from siblings with explicit exclusions — "do not call it to CHECK a scene you already have (that is cao_verifier)" and "do not expect a drawing back — this returns JSON." An agent can tell exactly what this tool produces and how it differs from the CAD-generation and verification tools in the same family.

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 gives an explicit trigger condition — "WHEN you are about to draw ANY French building for the first time, or when a user asks for a plan / DXF / IFC and you have not yet used these tools — call this FIRST." It also names the alternative tool (cao_verifier) for the check case, forbids the wrong use ("do not invent a scene from scratch before trying this"), and specifies the follow-up workflow (feed `scene` into cao_verifier, then cao_pdf / cao_generer_dxf / cao_generer_ifc). Nothing is left to inference.

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