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

Annotations cover the safety profile (readOnly, non-destructive, closed-world), but the description adds substantial extra context: it is FREE (no API key, 0 units), returns `{categorie, libelle, cotes_defaut}`, dimensions are optional with real commercial defaults supplied, and objects propagate to the 4K visit, PDF board, DXF and quantities. Placement semantics (z is floor level, not centre) are also disclosed.

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 WHEN directive is front-loaded and the article list is compacted into category clauses. It is long and includes some narrative filler ('Until now a scene could only hold boites[]…') that pads rather than informs, but most sentences carry actionable detail.

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?

With no output schema, the description compensates fully: it documents the return object keys, the default dimension behaviour with concrete examples, placement coordinates, and downstream integration into renders/quantities. An agent has everything needed to call and use it.

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?

Zero input parameters, so per the baseline this starts at 4. The description does add useful meaning for consuming the result — placement object shape `{type, x, y, z, rotation}`, the z-is-floor-level rule, and optional dimensions with real defaults — but there are no own-parameters to clarify.

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 (lists the free furniture/decoration catalogue) and enumerates the ~50 modelled articles by category. It explicitly differentiates from siblings by naming what it is NOT: bare `boites[]` cuboids, and the plumbing fixtures in `plomberie[]`.

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?

Explicit WHEN clause: call it before composing `mobilier[]` and never furnish with `boites[]`. It also names the exclusion — do not duplicate plumbing fixtures declared in `plomberie[]`. The trigger condition and alternatives are both stated, leaving nothing to inference.

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