immobilier

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

The description explicitly discloses a critical behavioral constraint: it refuses publication (publier=true est refusé) and only produces a draft. This is reinforced by the schema's statut enum limited to 'brouillon'. No annotations exist to carry this burden, so the description does it thoroughly.

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 concise and well-structured: a trigger clause, an action clause, and a clear constraint. It avoids redundancy with the schema and is not overly verbose.

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?

The description covers the tool's purpose, output format (texte_brut + html), and the crucial non-publication constraint. It does not enumerate all parameters, but the schema covers them. Given the complexity and lack of annotations, the context is sufficiently complete.

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?

The schema already provides 100% coverage with detailed descriptions for all 14 parameters. The tool description adds no additional parameter-level semantics, so the baseline of 3 is appropriate.

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 clearly states the tool drafts a rental listing (brouillon) when a vacant property needs an ad. It also distinguishes itself by explicitly stating it never publishes, which is a key differentiator from other tools.

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 provides a clear trigger condition ('QUAND un bien vacant doit être mis en location') and explicitly states the service only drafts, never publishes, which guides when to use it. It could name alternative tools, but the condition is sufficient.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses that the result is a ready-to-send letter rather than an actual send ('Courrier ... prêt à envoyer' vs 'notifie'), and reveals the always-on window-envelope layout and PDF endpoint. It also surfaces a 5-digit postal-code validation that an agent would otherwise only discover at runtime.

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?

Each clause carries distinct information: trigger, prerequisite, output, envelope constraint, address preference, and validation rule. The trigger is front-loaded, there is no filler, and the length is proportionate to a 12-parameter document-generation tool.

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 document-generation tool with no output schema or annotations, the description explains when to use it, what it produces (HTML and PDF via endpoint), input preferences, and a key validation rule. It also names the calculation sibling tool so the agent can orchestrate the workflow correctly; nothing essential is missing.

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?

The input schema already covers 100% of the 12 parameters, so the baseline is 3. The description adds actionable semantics beyond the schema: prefer locataire_adresse (postal) over logement_adresse (property) for the window, and enforce a 5-digit postal code. This improves correct parameter population.

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 precise action: notify the tenant of an IRL rent revision via a ready-to-send letter. It identifies the resource ('Courrier de révision de loyer IRL'), the output formats (HTML/PDF), and explicitly distinguishes it from irl_revision_loyer, whose calculation must precede this tool.

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 'QUAND' condition (revision already calculated, need to notify tenant by mail) and instructs to calculate with irl_revision_loyer first. It also gives address-choice guidance (postal address vs property address) and a mandatory postal-code guardrail, leaving no doubt when to invoke this tool.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes further: output is full HTML returned inline ('ni fichier, ni URL, ni PDF'), nothing is stored or sent, and there is no access to the Synergieloc parc. These are non-obvious behavioral facts an agent needs.

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?

Front-loaded with the usage condition and output-format facts, and caps-based emphasis aids scanning. Slightly diluted by the promotional paragraph (subscription URL, plan pricing) that does not help an agent invoke the tool correctly.

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 15-param, no-output-schema tool, the description covers the missing pieces: output format, no persistence, no file/URL, and the routing decision versus quittance_loyer. It stops short of noting the 3 required parameters, but the schema carries those.

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 only a little beyond the schema — the fenêtre-envelope placement of locataire_adresse ('poussée À DROITE') — while the other 14 parameters are fully documented in the schema itself.

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 (génère un avis d'échéance) and resource (appel du loyer du mois), and explicitly names the sibling it must not be confused with (quittance_loyer). An agent can distinguish it from the 40+ siblings immediately.

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?

Front-loads 'QUAND le bailleur doit APPELER le loyer du mois, AVANT paiement' and contrasts it with quittance_loyer which attests 'APRÈS coup'. That is an explicit when-to-use plus when-not-to-use distinction.

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

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

Goes well beyond the annotations (readOnly/idempotent/non-destructive) by disclosing side-effect boundaries: nothing is persisted server-side, no message is emailed to the provider, the output is inline HTML with no file, URL, or PDF. These are the facts an agent needs before deciding the user must still act manually, and they are consistent with the read-only 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?

Front-loads the trigger, then differentiation, then output/side-effect behavior in a compact three-sentence block. Slightly dense and the "imprimez-le ou convertissez-le vous-même" line is more advisory than essential, but no sentence is wasted.

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 12-parameter generation tool with no output schema, the description supplies the missing return contract (complete HTML inline, no attachment) and the non-persistence/no-send guarantees, which is precisely the information the schema cannot convey.

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 schema already documents all 12 parameters with examples and semantics (urgency levels, cost ceiling, lot refactoring). The description adds no per-parameter meaning, so the baseline 3 applies.

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 action (producing the bon de commande that authorizes a repair expense) and explicitly names the two siblings it must not be confused with — devis_travaux (pricing request) and compte_rendu_chantier (after-the-fact report). An agent can route correctly without opening any schema.

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 trigger ("QUAND une réparation doit être commandée...") and gives the exclusion conditions for both alternatives in the same breath. This is exactly the when-to-use / when-not-to-use guidance the dimension asks for.

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

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

With no annotations, the description carries the full burden and does so well: it states that the tool contains no tenant data, is public rules only, is a GET request, and that server-side guardrails remain authoritative. This makes side effects and data scope clear.

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 relatively compact and front-loaded, but the use of all-caps and repeated emphasis ('WHEN', 'FREE', 'NO tenant data') adds slight noise. Still, each sentence contributes useful usage or safety information.

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 simple one-parameter tool with no output schema, the description provides everything needed: endpoint, query parameter, domains, response shape, data scope, and usage priority. No critical context is missing.

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?

The single optional 'domaine' parameter is described in both the input schema and the tool description, including a concrete query example. The enum values are listed and the default behavior when omitted is explicitly stated.

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 clearly identifies the tool as a versioned playbook of best practices for MCP/API agents, naming the resource, endpoint, and return structure. It distinguishes itself from sibling tools by emphasizing its 'first call' meta-role and its domain-filterable rules.

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?

It explicitly instructs the agent to call it first upon discovering the server and again if cached instructions may be stale. It also notes that no API key/units are required and that server-side guardrails remain authoritative, giving clear usage boundaries.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds non-obvious behavioral and workflow context: the output is HTML with a separate PDF endpoint, the address-block recipient is the agency, and the document should be filed locally after receipt. This goes beyond what annotations provide and does not contradict them.

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 four short, front-loaded sentence fragments, and each earns its place: trigger, resource/format, recipient, and post-receipt action. There is no filler or redundant restatement of the tool name.

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 17-parameter document generator with no output schema, the description covers the essential decision and outcome facts: when to use it, what it produces (HTML, with PDF available via a specific endpoint), who the recipient is, and what to do with the result. It does not explicitly state the response shape, but it names the HTML format and the 100% schema coverage makes enumerating parameters unnecessary.

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 input schema already documents all 17 parameters in detail. The description's only parameter-related hint is the address-block recipient, which reinforces 'agence_adresse' but adds no new semantics. Per the baseline rule, this warrants a 3.

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 trigger ('QUAND un candidat constitue son dossier pour un logement') and a specific resource ('Dossier de CANDIDATURE locataire'), which clearly identifies this as the tenant-application document tool. It also adds output format and recipient context that distinguish it from sibling document tools. However, it never states the operative verb explicitly (e.g., 'génère' or 'crée'), so the action is implied rather than named.

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 explicitly defines when to use the tool: when a candidate is assembling a rental application file. It also provides practical routing guidance ('Destinataire fenêtre = agence') and a post-receipt action ('À classer dans le dossier local après réception'). It does not list exclusions or name alternative tools, but none of the siblings appears to be a close competitor, so the trigger is sufficient.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the return shape ({topics, conflits, alertes, bcf_base64}) and instructs the caller to write bcf_base64 to a .bcfzip file — genuinely useful operational detail. It reveals that each topic selects objects by IFC GlobalId with a camera placed in front, which is helpful. However, it does not disclose auth/permission needs, whether the operation is non-destructive (it appears to be a pure export), or any limits on scene size. For a complex export tool with zero annotation coverage, this is partial but not complete.

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 front-loaded with the critical when-to-use signal and packs useful output format info into a compact paragraph. However, it is a single dense run-on sentence mixing English and French (conflits, alertes) that forces the agent to parse mixed terminology. The sentence is information-dense but structurally heavy; a cleaner split would improve scannability.

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 compensates by specifying the exact return shape and the file-writing instruction, which is the essential operational knowledge. The 100% schema coverage carries the parameter documentation burden, and the description handles the invocation trigger and output contract. Remaining gaps (auth, limits) are minor given the tool's export nature and the schema richness.

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 schema already documents all 13 parameters in detail (murs, boites, toitures, etc. all carry rich descriptions). The description adds value by explaining the ifc parameter overrides scene fields and by describing the output contract, but it does not add meaning to the individual scene parameters beyond what the schema provides. Baseline 3 is appropriate given the high coverage.

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 clear verb+resource: export clashes and control alerts as a BCF 2.1 zip readable in specific BIM tools, with a defined mapping (one Clash topic per clash, one Issue topic per alert). It names target applications (Solibri, BIMcollab, Navisworks, Revit, Archicad) which grounds the purpose. It doesn't explicitly distinguish itself from the sibling cao_conflits_ifc (clash detection), but the BCF-export outcome is distinctive enough that an agent can tell them apart.

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 opens with an explicit when-to-use condition: 'WHEN clashes and control alerts must leave as a BCF 2.1 zip'. It also states the input alternative ('pass a scene or ifc'), covering the two main invocation modes. It doesn't name specific sibling alternatives or when-not-to-use conditions, but the trigger framing is clear and actionable for an agent.

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

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

With no annotations, the description carries the full burden. It discloses the computation method, thresholds, and explicitly lists intended geometry counted in 'ignores' (wall-slab bearings, wall corner/T joints, objects on rug/deck, doors). It also notes GlobalIds are kept for IFC input. It does not explicitly state read-only behavior, but 'detect' implies non-destructive.

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 packs purpose, method, thresholds, exclusions, input modes, and return structure into a single paragraph with no filler. It is front-loaded with the use case and precise details, though slightly long; every sentence earns its place.

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?

It explains conflict detection and the 'ignores' field, but the return fields 'elements' and 'boite_modele' are only named, not described. Without an output schema, this leaves ambiguity about their content. It also omits error behavior. For a complex tool with no annotations, this is a notable 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?

Schema coverage is 100%, so the schema already documents every parameter. The description adds only the mode distinction (scene vs ifc) and references cao_generer_ifc for the scene structure, which is helpful but minimal beyond what the schema provides.

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 ('detect') and resource ('real clashes') with precise thresholds (10 mm and 0.1 L) and method (volumes, horizontal slices). It clearly distinguishes itself from sibling tools like cao_valider_ifc or cao_bcf_ifc by specifying the clash-detection use case for BIM coordination.

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 explicitly with 'WHEN coordinating a BIM model' and describes two input modes (a scene same as cao_generer_ifc, or an IFC text). It does not explicitly list alternatives or exclusions, but the context of when to use it is clear.

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

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

No annotations are supplied, so the description carries the full burden — and it delivers: attached walls are extended, furniture follows moved walls, obstructing objects are pushed, switches are relocated out of door openings, results are re-validated, defect-creating walls are rejected, and stacked load-bearing walls never move alone. It also discloses the deterministic-vs-language-model switch via `modele`.

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?

Front-loaded with the WHEN clause and dense throughout, with the downstream-routing note and return-field list at the end. A few parenthetical examples could be trimmed, but almost every clause carries behavioral information.

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 enumerates the return fields (compris, source, operations, journal, erreurs, nouvelles_alertes, valide, scene, difference) and tells the agent what to do with `scene`. For a tool with nested objects and a nested `scene` parameter, nothing needed to call it correctly is missing.

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%, so the baseline is 3; the description adds real meaning beyond it by clarifying that `operations` come from the catalogue endpoint and are applied without the language model, and that `scene` shares the cao_generer_ifc format.

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 (natural-language requests become typed millimetre-precise operations on an existing building scene) with concrete trigger examples. It also positions itself against siblings by routing its `scene` output to cao_generer_ifc or cao_pdf.

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 'WHEN a user asks to change an existing building scene in plain words' clause plus quoted examples give clear triggering conditions, and the `operations` path is named as an alternative when no language model is wanted. It never states a negative case (e.g. 'do not use to create a scene from scratch'), which cao_generer_ifc only implies.

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

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.

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

With no annotations, the description carries the full burden and it does well: it discloses validation behavior (out-of-series values refused, accessibility per the 24 Dec 2015 decree), the export to IFC with shared geometry/lining/panels, and that it is free with no key. The remaining gap is that it is unclear how an 'ouvertures[]' entry is supplied given the tool takes no input parameters.

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-scenario is front-loaded, which is good, but the body is a single overloaded sentence packed with semicolons, a long parenthetical enumeration of family types, and an embedded validation clause. The family list could be trimmed without losing agent-facing value.

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?

There is no output schema and no annotations, so the description must stand alone, and it fairly comprehensively covers what families exist, how entries are validated, and that results are exported to IFC. The one unresolved point is the mechanism by which an `ouvertures[]` entry reaches a parameterless tool.

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?

The tool has zero input parameters, so the baseline is 4. The description references `famille` and `parametres` fields of an `ouvertures[]` entry, but these are not part of this tool's own schema, so they add no parameter semantics beyond the baseline.

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 and resource (lists the parametric door/window families) and contrasts with the alternative approach of 'free-size holes'. An agent can understand the tool is a catalog of bounded joinery families. It does not name a sibling tool explicitly, so it stops short of a 5.

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 'WHEN you place doors or windows ... and want real, orderable joinery' clause gives a clear situational trigger for use. However, it never names an alternative sibling (e.g. cao_generer_ifc, cao_importer_ifc) or an exclusion condition, so no explicit routing guidance is provided.

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

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

With no annotations provided, the description carries the full burden. It discloses that the DXF arrives inline as text, no file is stored, and the agent must write it to a file itself. It also explains the return fields (dxf, faces, entites_2d, unites, note, alertes) and mentions the coordinate system and unit handling. It stops short of describing error scenarios or authentication, but for a generation tool this is adequate.

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 dense but every sentence carries value: usage trigger, prerequisite call, schema reference, return format, file-handling note, and sibling differentiation. It is front-loaded with the critical usage guidance. Slightly long but not verbose, earning a 4.

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 12 parameters, nested objects, and no output schema, the description covers the key operational details: return structure, unit system, coordinate frame, and the fact that some parameters (reseaux, plomberie, etc.) are only used by cao_pdf. It could mention error handling or typical failure modes, but it is largely complete 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% – every parameter has a detailed description. The tool description adds a few global clarifications (millimetres, single plan frame, no recentring, scene schema URL) that complement the schema, but does not elaborate on each parameter. This is acceptable given the schema's richness, hence a baseline 3.

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 clearly states the tool generates an AutoCAD DXF from a building scene, and explicitly distinguishes it from cao_generer_ifc by mentioning BIM objects. It also mentions the schema endpoint and return structure, making the purpose unambiguous.

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 provides explicit when-to-use guidance: when a real CAD file is needed. It also tells the agent to call cao_verifier first to catch geometry mistakes, and to use cao_generer_ifc instead when BIM objects are required. No other exclusions are needed.

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

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

There are no annotations, so the description carries the full behavioral burden, and it delivers: it discloses that the IFC file arrives INLINE as text with no download URL and nothing stored server-side, that the agent must write the file itself, that output is JSON {ifc, elements, schema}, that units are millimetres with Lambert-93 scaling at 0.001, and that output passes IFC4 schema + EXPRESS validation. This is rich behavioral disclosure.

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 front-loads the decisive trigger condition well, but then trails into a long promotional list of IFC features (GUIDs, space areas, stair flights, Pset/Qto, etc.) that mostly documents guarantees rather than selection or usage. It is dense but several sentences could be trimmed without losing call-correctness intent.

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 12-parameter tool with no output schema, the description thoroughly covers the output contract (fields, inline nature, storage-limit, manual file write), unit convention, georeferencing scale, and call-order dependencies. It does not enumerate how each existing parameter maps into the IFC output, but the schema and the stated integration rules cover the key decision points.

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?

The schema descriptions already cover 100% of parameters in detail (mm units, centre-vs-corner placement, defaults, material keys, composition semantics), so the description adds little per-parameter value. It does add cross-cutting guidance (consistent origin never recentered, 'omit epaisseur on the load-bearing layer', compositions{} replacing type compositions and the Hypothese flag), but this is supplementary rather than essential.

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 the specific verb+resource: generate a real IFC4 BIM file from a building scene, openable in Revit/ArchiCAD/Solibri. It distinguishes itself from the drawing-producing sibling by the contrast 'not just a drawing' and explicitly ties itself to cao_generer_dxf ('Same scene as cao_generer_dxf'), so an agent can tell them apart.

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?

It opens with an explicit trigger condition ('WHEN the drawing must leave as a real BIM file...'), names the pre-requisite tool ('Call cao_verifier first') and the validation alternative ('Validate locally with cao_valider_ifc'), and identifies the sibling with the same input scene (cao_generer_dxf). This provides both when-to-use and call-order guidance beyond the docs.

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

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

With no annotations, the description carries the behavioral burden, and it does so well: it says the tool checks every specification, returns applicable and failing elements with reasons, conditionally produces BCF 2.1 topics, and falls back to a French housing IDS when ids is omitted. It does not disclose the exact response shape or error behavior, but there is no contradiction or hidden mutating side-effect implied.

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 dense and front-loaded with the key use case, and every clause adds relevant information: scope, checked facets, output, BCF behavior, and the default French IDS. It is long and somewhat run-on, but for a tool with this many behaviors it remains focused and free of fluff.

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?

Given the large input schema and absent output schema, the description explains the essential behavior: what is checked, what is returned, what bcf does, and how the default IDS works. It does not fully specify the response structure or failure semantics, but it provides enough context for an agent to select and invoke the tool 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 description coverage is 100%, so the baseline is 3 and the schema already documents all parameters thoroughly. The description mainly restates what bcf and ids do rather than adding genuinely new parameter semantics, so it earns the baseline but not more.

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 resource: checking an IDS 1.0 requirements file against a model before delivery, and enumerates what is verified. It is clearly distinct from most siblings by focusing on IDS conformance, though it never names or explicitly contrasts a closer sibling such as cao_verifier or cao_valider_ifc.

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 opening WHEN clause gives a clear trigger: a BIM manager's information requirements must be checked against a model before delivery. It also explains the default French IDS behavior and the bcf option, but it gives no explicit when-not-to-use guidance or named alternatives among the cao_* tools.

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

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

With no annotations, the description carries the full burden and largely succeeds: it names the return keys {scene, rapport, controles, metres}, states conflits:true adds clash detection and studio:true opens a 4K video studio plus VR tour URLs. It omits permissions, rate limits, and failure behavior.

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?

One dense sentence chain, but the trigger condition is front-loaded and every clause carries information (elements, GlobalId, return keys, flag effects). It is heavy for a single paragraph but not padded.

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 supplies the return structure and flag-dependent side effects, which is what an agent needs to pick this tool and set flags. Missing only auth/error context, which is a minor gap for an import tool.

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 already 100%, but the description adds real meaning on top: studio:true 'opens the 4K video studio and the VR tour', conflits:true 'adds clashes', metres:true equals quantities, and scene is the reusable object. This goes beyond the schema's one-line parameter 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?

States a specific verb and resource — converting IFC text into a CAO scene — and enumerates the produced elements (walls, doors, windows, stair flights, railings, rooms, furniture, roof) and the GlobalId retention. This clearly distinguishes it from siblings like cao_generer_ifc or cao_valider_ifc, which do not import-and-convert with this element coverage.

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 'WHEN an architect sends an IFC ... and you must check it with our rules' trigger gives an explicit usage context, and it says to reuse `scene` with other cao_* tools. It stops short of naming when NOT to use it versus cao_generer_ifc or cao_valider_ifc.

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

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

No annotations are provided, so the description carries full behavioral disclosure. It discloses that the tool performs a geometry audit and returns alertes[], which is a meaningful behavioral trait. However, it does not state whether the tool modifies the scene, what side effects exist (if any), or the structure of the returned quantities. This is a partial disclosure but not comprehensive.

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 two sentences long, front-loads the purpose and usage context, and contains zero filler. It efficiently conveys the core function and the alertes output in a compact form.

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?

Given the tool's complexity (12 top-level parameters, nested objects, no output schema), the description is too sparse. It does not describe the structure of the returned quantities, how they relate to the input scene, or any assumptions about units (though the schema covers units). It only mentions alertes, leaving an agent without enough context to interpret results or anticipate the output format. The description should provide more detail about the return value and any prerequisites.

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?

The schema description coverage is 100%, so every parameter is already documented in the input schema. The description adds no parameter-specific guidance beyond stating it computes from the scene. With full schema coverage, a baseline of 3 is appropriate; the description does not need to compensate.

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 clearly states the tool computes quantities (metrés) from a CAO scene and returns geometry audit alerts. It provides explicit usage context (pricing, ordering, checking quotes) and distinguishes itself from sibling cao_generer_dxf by noting the same scene but different output. The verb 'compute' and resource 'quantities from a CAO scene' are specific and unambiguous.

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 when-to-use ('WHEN you need FIGURES from a design — to price a job, order materials, or check a quote') and references the relationship with cao_generer_dxf. However, it does not mention alternatives like cao_pdf or cao_generer_ifc, nor does it state when not to use this tool, leaving some routing ambiguity.

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

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

With no annotations, the description carries the full burden for behavior. It explains the return format (categorie, libelle, cotes_defaut), that dimensions are optional with real commercial defaults, and that items appear in 4K visit, PDF, DXF, and quantities. It does not explicitly state read-only but it is clearly a fetch operation, so the behavior is well conveyed though not explicitly labelled as non-destructive.

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 detailed and well-organized, starting with the core purpose, then listing categories, return format, placement, and integration with other outputs. It is slightly long but each segment provides necessary context. The structure is logical, allowing quick extraction of key facts, though it could be tightened without losing value.

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?

Given no output schema and no annotations, the description must explain the tool's output and integration context. It fully does so: describes the return structure, dimension defaults, placement semantics, and warns about duplication with plomberie[]. It also indicates how results are consumed (4K visit, PDF, DXF, quantities). This is complete for an agent to use the tool 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?

The input schema is empty (0 parameters), so schema coverage is 100%. The description adds no parameter-specific information because there are none to describe. Per the baseline, a score of 3 is appropriate since the description does not need to clarify parameters that do not exist.

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 clearly states the tool's purpose: to provide a catalog of real furniture and decoration objects for furnishing scenes, with explicit context ('call this BEFORE composing mobilier[]') and a contrast to the 'boites[]' placeholder. It is unambiguous and distinct from sibling tools like DXF generation or rendering.

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 explicit when-to-use guidance (before composing mobilier[]), when-not-to-use (avoid boites[], do not duplicate plumbing fixtures), and direct invocation ('REST: GET /api/v1/cao/mobilier'). It also explains placement details with z as floor level. This leaves no ambiguity about how to invoke and use the tool.

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

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

The description discloses important behavioral traits beyond what annotations provide (no annotations exist here): the sheet embeds an orange alert banner when issues remain, the tool returns JSON with specific fields (html, alertes, alertes_ok, resume), and it shares the same scene as cao_generer_dxf. It also warns about the prerequisite verification step. While it doesn't detail every side effect, it covers the critical behavioral context for a generation 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 compact and front-loaded with the key usage context (handover scenario) before listing deliverables. The IMPORTANT note about cao_verifier is placed prominently. It's slightly dense with the return format and scene-sharing note, but every sentence earns its place and there's no wasted text.

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 generation tool with 14 parameters, 100% schema coverage, and no output schema, the description covers the essential context: when to use it, what it produces, the prerequisite verification step, the alert banner behavior, and the return format. The only minor gap is that it doesn't explicitly describe the output schema structure beyond naming the JSON fields, but the field names are self-explanatory.

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 schema already documents all 14 parameters thoroughly. The description adds context about the scene being shared with cao_generer_dxf and the return format, but doesn't need to explain individual parameters since the schema does that comprehensively. Baseline 3 is appropriate when the schema carries the full parameter documentation burden.

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 clearly states the tool's purpose: generate a professional technical sheet from a CAO scene for handover to a client, architect, or planning office. It specifies the exact deliverables (top view, elevations, shaded axonometric, optional MEP plan) and distinguishes it from siblings like cao_generer_dxf and cao_verifier by naming them 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?

The description explicitly states when to use this tool (when the design must be handed over to a client, architect, or planning office) and provides a critical usage instruction: call cao_verifier FIRST and fix critical alerts before delivering. It also names the sibling cao_generer_dxf as sharing the same scene, which helps an agent understand the relationship between tools.

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

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

With no annotations, the description carries full behavioral burden. It discloses the non-destructive guarantee ('Adds what is missing, never removes'), the return contract ({scene, rapport, controles}), and a safety limitation (slab span check is 'indicative pre-design, to be validated by a structural engineer'). No annotation contradiction exists.

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 text is information-dense and front-loaded with the WHEN trigger, and nothing is superfluous. However, it is delivered as one long run-on paragraph; a structured bulleted list would be far more scannable for an agent, so it is not exemplary.

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 19-parameter tool with no output schema, the description covers the main gaps: return shape, next step, non-destructive behavior, and engineering caveats. It does not explain the content or follow-up of 'controles' when it flags issues, but the schema carries the heavy lifting for inputs.

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 per-parameter descriptions already explain units, defaults, axes, and coordinate frames. The top-level description adds program context about which rules each parameter group implements, but no parameter-specific semantics beyond what the schema already provides.

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 specific operation — completing a building scene with structure and building services under French rules — and enumerates the exact systems (lintels, strip footings, NF C 15-100 electrical, single-flow ventilation, drainage, heating). It also explicitly positions itself as the pre-export/completion step and routes the returned scene to cao_generer_ifc, making it clearly distinguishable from sibling cao_* tools.

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 opening 'WHEN a building scene must be completed with structure and building services... before BIM export or quoting' gives a clear trigger and context. It lacks an explicit when-not or named alternatives, but the next-step mention of cao_generer_ifc effectively disambiguates the workflow.

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

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

With no annotations present, the description carries full weight for safety disclosure, and it delivers: 'Read-only — nothing is drawn, saved or sent anywhere.' It also clarifies the return behavior ('Returns the picture itself, never a link') and the two concrete formats (SVG markup as text, PNG as an image). This is substantial beyond the (empty) annotation layer.

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 about 70 words and front-loads the core intent ('WHEN you want to SEE the plan…'), then gives the differentiation, output details, and safety warning. Every sentence carries information; there is no filler or redundancy. This is a model of concise, structured documentation.

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 preview tool, the description tells the agent when to use it, what it renders, what format it returns, and that it is read-only. The schema independently documents every input (units, coordinate frame, which fields affect only cao_pdf) so the agent can pass a correct scene. The only small gap is that the description does not list which scene elements appear in the preview, but the schema's per-field notes largely cover that. Overall, nothing critical is missing.

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%, with even enum values and defaults documented inline)Skip. The description itself only touches the format parameter ('format=svg gives SVG markup as text, format=png gives an MCP image'), which repeats what the schema already states. Per the baseline rule for high coverage, a 3 is appropriate since the schema does the heavy lifting.

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 verb and resource: 'Top-down preview of a CAO scene.' It also differentiates from the sibling cao_verifier, noting that tool is for structured alerts while this is for visual double-checking. This lets an agent pick the right tool without opening schemas.

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 explicitly says when to use this tool ('when you want to SEE the plan before delivering it') and when not to ('Prefer cao_verifier before this for structured alerts'). It names the alternative and the condition, leaving no ambiguity about the appropriate scenario.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the output format ({ok, schema_ifc4, regles, problemes}) and enumerates the checks (IFC4 schema, EXPRESS rules, millimetre units, material layers, etc.), which tells the agent what to expect. It does not explicitly state that the operation is read-only or non-destructive, but the nature of a validation tool implies it. Given the absence of annotations, the description is reasonably transparent, though it could explicitly mention side effects (or lack thereof).

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 compact two-sentence structure with the critical usage trigger ('WHEN you need to check...') front-loaded, followed by the return contract and the list of checks. Every sentence earns its place—there is no fluff or repetition. This is a model of concise, front-loaded documentation.

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?

Given the tool's complexity (12 parameters, nested objects) and the absence of an output schema, the description provides a clear high-level purpose and return shape. It also gives a key contextual hint ('without a buildingSMART account' and 'Same scene as cao_generer_ifc') that helps an agent decide when to call it. However, it does not explain how the validation results should be interpreted or what to do with 'problemes', and it doesn't cover edge cases or prerequisites beyond the schema. For a validation tool, this is adequate but not exhaustive.

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?

The input schema has 100% description coverage for all parameters, so the schema already documents each parameter thoroughly (e.g., units, defaults, meanings). The description adds no parameter-specific semantics beyond the schema; it only notes that the scene is the same as cao_generer_ifc, which is contextual but not parameter-level. Since the schema does the heavy lifting, a baseline of 3 is appropriate.

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 verb ('check an IFC scene') and a clear resource ('an IFC scene'), and explicitly differentiates from the sibling cao_generer_ifc ('Same scene as cao_generer_ifc'), making the tool's purpose unambiguous. It also lists the exact return structure and the validation checks performed, leaving no doubt about what the tool does.

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 opens with 'WHEN you need to check an IFC scene without a buildingSMART account', giving a clear trigger condition. It also references cao_generer_ifc as the sibling that shares the same scene, implying that cao_generer_ifc is for generation while this tool is for validation. However, it does not explicitly name alternative validation tools (e.g., cao_verifier, cao_conflits_ifc) or provide when-not-to-use guidance, so it falls short of a perfect 5.

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

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

With no annotations, the description carries the full burden and does so thoroughly. It states that no API key and 0 units are needed, declares it is non-destructive, discloses the output shape {ok, erreurs_schema, alertes[...], conseils, resume}, and documents how corrective fixes can be applied via POST endpoints.

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 overloaded and heavily repetitive. 'free/no key', 'correctifs[]', and POST endpoints are stressed multiple times, and many enumerated rules could be compressed. It is organized thematically, but sentences stop earning their place and the length harms immediate scanner usability.

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?

Given the high complexity of the tool (12 params, no output schema, no annotations), the description gives substantial context: it enumerates categories of checks (geometric, staircase, structural integrity, document completeness), describes the correctifs format with examples, and explains the separate POST endpoints. An agent can understand what result to expect and why the tool exists in the pipeline.

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% and the schema already explains murs, boites, ouvertures, toitures, and units in detail. The tool description adds little about those parameters, emphasizing the tool behavior rather than parameter semantics, so the coverage baseline of 3 is appropriate.

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 the verb and resource precisely: 'cheap geometric audit of a CAO scene' intended to stop wrong plans or broken visits. It distinguishes the tool from downstream generators by listing them explicitly (cao_pdf, cao_generer_dxf, cao_rendu, cao_visite_plan, cao_visite_studio) and positioning cao_verifier as the pre-step check.

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 is explicit about when to invoke it: 'WHEN a scene is composed and BEFORE cao_pdf / cao_generer_dxf / cao_rendu / cao_visite_plan / cao_visite_studio', and instructs the agent to fix severite=critique before delivery. It does not provide comparative exclusion for validation-focused siblings such as cao_valider_ifc or cao_ids_verifier, hence not a 5.

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

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

No annotations are provided, so the description carries the full burden — and it does substantial work: it discloses wall-collision behavior (a step ending inside a partition is refused and explained, not silently applied), the return shape {camera, etapes[], chemin[]} with reasons for refused steps, the API-key requirement, the GET endpoint for the action catalogue, and the HTTP method. It stops short of stating persistence or side effects of posting the scene, but for an unannotated tool this is strong disclosure.

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 informative but dense and somewhat sprawling — the action catalogue is inlined, endpoints and API-key details are mixed in, and the flow jumps between scenario, grammar, depuis, scene-posting, returns, and REST. It is front-loaded with the motivating scenario, which helps, but it is noticeably long for a tool description and could be tightened without losing value.

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 must explain return values — and it does ({camera, etapes[], chemin[]} with the reason for refused steps) — plus the action grammar, collision handling, and how to get the action catalogue. For a complex 15-parameter tool with nested objects, the core usage contract is well covered; the remaining parameters are documented by the schema, so nothing an agent needs to call it correctly is missing.

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%, so the baseline is 3, and the description adds genuine meaning to the core parameters: the full action catalogue for `actions`, the `depuis` waypoint provenance, and the purpose of posting the scene (murs for wall collision + landmarks). However, with 15 parameters the description only touches a few; the rest are left to the (well-covered) schema, which is acceptable but not exceptional.

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, distinctive purpose: pilot the camera via a sequence of named actions instead of coordinates, to fix a single wrong view. It explicitly contrasts with rewriting a whole `chemin` and names the related siblings (cao_visite_plan for waypoints, cao_visite_studio for rendering), so an agent can tell this tool apart without opening other definitions.

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?

Leads with a clear when-to-use trigger ('WHEN the automatic visit is good but ONE view is wrong... rewriting a whole chemin by hand would be absurd'), and explains how to start: from a `depuis` waypoint of a `chemin` from cao_visite_plan, or omit for an overall view. It also routes the output (`chemin`) back to cao_visite_studio, completing the workflow guidance.

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

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

No annotations are provided, so the description carries the full burden — and it delivers. It discloses the HTTP 400 construction_critique refusal behavior, the requirement to call cao_verifier first, the API-key requirement, the browser-GPU rendering engine, and the return shape with alertes/resume. For a mutation-heavy cinematic tool with zero annotation coverage, this is thorough and honest.

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 long but tightly front-loaded: trigger, then the critical prerequisite, then the refusal behavior, then purpose, return format, rendering, and adjustment. Each sentence earns its place and the ordering is pedagogically sound. It is dense, but the density is justified by the tool's complexity rather than padding.

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 and a complex 19-parameter tool, the description explains the return format explicitly ({plan:{objectif, cadence, plans[], chemin[]}, alertes[], resume}), the coordinate frame (mm, axes x=right y=depth z=height), the waypoint semantics, the room-detection pipeline, and the rendering/execution path. Little an agent needs to call it correctly is left unstated.

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, but the description adds real semantics beyond the schema: focal-length meaning per shot type (20 interior, 35 exterior, 50 closing, sub-16 fisheye), pacing thresholds (above ~1600 mm/s unwatchable), the adjustment workflow via objectif/cadence/chemin, and the lens catalogue endpoint. It genuinely helps an agent choose values.

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 verb-resource pair ('DIRECT the 4K cinematic visit of a CAO scene') and opens by differentiating the tool from flat-plan reading ('SEEN in motion rather than read on a flat plan'), which separates it from sibling cao_pdf/cao_rendu. It further clarifies it produces a shooting plan (plans/chemin) rather than the camera execution itself, disambiguating it from cao_visite_camera.

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 opening 'WHEN... rather than read on a flat plan' gives an explicit trigger condition, and the tool names a hard prerequisite ('call cao_verifier FIRST and fix every severite=critique'). It also explains the retry workflow via POST /api/v1/cao/integrite. It does not explicitly name an alternative sibling to switch to, but the contrast with the flat-plan use case and the prerequisite are clear enough.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description stays consistent while adding genuinely new behavioral context: the report is returned inline as full HTML, with no file, no URL, and nothing saved or transmitted to the client. This tells the agent the output is not persisted and not delivered — useful beyond the 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?

Front-loaded with 'QUAND', then purpose, sibling differentiation, and output format in three tight sentences. No filler, every clause carries information.

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?

No output schema exists, and the description compensates by explaining exactly what is returned (inline HTML, nothing stored or sent). With all parameters documented and safety covered by annotations, nothing an agent needs is missing.

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 all ten parameters are already documented in the schema. The description adds no parameter syntax or format details beyond that, so baseline 3 applies.

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 specific verb+resource — producing a site progress report for the project owner — and immediately distinguishes it from two siblings (bon_intervention, fiche_mission) with the differentiator in parentheses. An agent can identify the tool's job without opening the schema.

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?

It states when to use it ('après une visite', to report progress to the maître d'ouvrage) and explicitly names the alternatives with the condition that selects each (command a repair vs. frame a future intervention). Both when and when-not are covered.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond that: it returns the full letter as HTML in the response, not as a file or URL, and sends nothing to the recipient. These details matter for a generation tool but do not cover permissions or rate limits.

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?

Front-loads the usage condition, then clarifies non-actions, then states the output format. Every sentence earns its place with no filler or repetition. Well-sized for an 11-parameter tool.

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?

Given the rich annotations, full parameter coverage, and no output schema, the description supplies the missing pieces: output format (HTML in response), absence of external sending, and clear usage conditions. Nothing an agent needs to call this correctly is missing.

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 every parameter is already documented in the schema. The description does not add meaning beyond the schema, only implying that a 'créneau' is supplied. With full schema coverage, a baseline 3 is appropriate.

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 and resource: 'rédige la lettre de confirmation d'un créneau que vous lui donnez.' It explicitly rules out reservation and calendar lookup, distinguishing it from any scheduling siblings. An agent can immediately tell this generates a confirmation letter, not a booking.

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 'QUAND' clause naming the trigger (a meeting already booked and needing written confirmation) and gives examples. It also clarifies what the tool is NOT for ('ne réserve rien et ne consulte aucun agenda'), though it does not name a specific alternative tool. Clear context and exclusions, but no sibling routing.

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

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 does well: it discloses that nothing is checked against URSSAF or a greffe, that no attestation is authenticated, and that the output is a complete HTML document returned in the response (not a file, URL, or PDF). It does not cover error handling or what happens when required fields like siret are absent.

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 usage condition, then scope caveats, then output format, then data shape — a sensible ordering. It is dense and roughly at the limit of useful length, but every sentence adds a distinct constraint rather than restating the name.

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 no-annotation tool with no output schema, the description supplies the missing pieces: when to use it, what it deliberately does not do, and the return format (HTML in the response). It leaves minor gaps such as behavior with missing or malformed pieces input, but the essential call-time information is present.

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 already 100%, so the baseline is 3. The description goes further by spelling out the shape of the nested 'pieces[]' objects ({type, statut, numero, date_expiration}), which the schema leaves as an untyped array of objects — genuine added meaning beyond the structured field.

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 verb and resource ('vérifier qu'un artisan est en règle', 'Checklist conformité artisan') and enumerates the exact documents covered (RC Pro, décennale, URSSAF, KBIS). It also pre-empts confusion with a real verification tool by clarifying that it only formats the pieces you supply. No sibling tool in the list overlaps with this scope.

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 opening 'QUAND il faut vérifier qu'un artisan est en règle avant de lui confier un chantier' gives an explicit, concrete usage trigger. The 'c'est une checklist, pas un contrôle' disclaimer implicitly marks the boundary where a real verification would be needed instead, but no alternative tool is named.

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

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

The annotations already declare a safe, idempotent, non-destructive local read, and the description adds substantial context on top: nothing is stored or sent, no file/URL/PDF is produced, the recipient is the owner, and the figures are supplied by the caller from a local folder. That is exactly the extra behavioural detail annotations cannot convey.

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?

Front-loaded with the usage condition, then the deliverable, then the output-format and no-persistence constraints. Every clause carries information; no filler.

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 15-parameter generation tool with full schema coverage and annotations covering the safety profile, the description closes the remaining gap by explaining the HTML-in-response return and the no-side-effect behaviour. Minor omissions (e.g. what happens when optional blocks are absent) are not material.

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 schema already documents all 15 parameters in detail (including the warning that solde is passed through unrecalculated). The description only adds the general point that recettes/dépenses/honoraires/solde come from the agent's local folder, which is marginal beyond the schema.

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 specific deliverable — a simplified 'COMPTE RENDU DE GESTION' for a property owner — and states its concrete output form (full HTML in the response). It is clearly distinguishable from siblings such as quittance_loyer or regularisation_charges, though it never names an alternative directly.

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?

It opens with an explicit trigger: 'QUAND il faut rendre compte au propriétaire (fin de trimestre, d'exercice, ou à sa demande)', which gives real when-to-use conditions. It also routes external clients to /api-ia, but stops short of naming a sibling tool for the alternative reporting cases.

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

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

With no annotations, the description carries the full burden and does disclose auth requirements (API key, X-Make-Secret/X-API-Key), cost (0 units), data retention ('jamais conservée après la décision'), and constraints ('Never invent offers/prices'). However, it introduces an internal contradiction: it says Synergieloc decides cible, while the input schema exposes cible as a parameter. This leaves an agent uncertain about whether to send that field.

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 dense but front-loaded with the trigger condition and immediately useful constraints. Endpoint, auth, and cost details are packed in efficiently. Every clause contributes operational information, though the mixed-language style and run-on feel slightly hurt readability.

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?

The description covers the workflow, authentication, cost, and follow-up endpoint. Since there is no output schema, it should more explicitly describe the decision response structure; 'cible, campagne and actions[]' is only a minimal hint. The input/output ambiguity around cible also leaves an important gap in understanding the full contract.

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%, so the baseline is 3. The description adds a useful global constraint ('Pass prospect info only') and warns against inventing offers/prices, which relates to the produit parameter. But the cible contradiction undermines the added meaning and can mislead an agent about a specific parameter's role.

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 clearly identifies the tool as an authenticated decision engine for outreach/campaigns: it decides what to do with each collected prospect. This distinguishes it from the sibling tools, which are mostly document/CAO/real-estate operations. However, the claim that 'Synergieloc decides cible' is partially contradicted by the presence of a cible input parameter in the schema, which muddies the stated purpose.

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 an outreach scenario has collected prospects') and a mandatory ordering ('MUST call this before sending commercial email'). It also tells the agent what to do after the decision ('follow actions envoyer_offre → POST /api/v1/agent/demarchage'). There is no explicit when-not-to-use or named alternative, 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.

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

With no annotations, the description carries the burden and does disclose real behavior: it proposes an accounting entry, triggers a next action, includes a commercial reminder in plan Agent, and has no bank access. It does not specify persistence or reversibility, but the disclosed workflow is materially useful.

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?

Every sentence earns its place: trigger, ordering, workflow, constraint, parameter rule, side-effect reminder, and endpoint. The key use case is front-loaded in caps, making it scannable despite the dense single paragraph.

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 7-parameter tool with no annotations and no output schema, the description covers trigger, ordering, data source choice, output proposal, and REST route. It could add expected response format or side-effect confirmation, but the essential calling context is present.

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?

Input schema already documents all 7 parameters (100% coverage), so the baseline is 3. The description adds value by linking source=extrait_bancaire to a concrete condition and mapping the client-confirmed date + montant to inputs.

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?

Description names the exact trigger (client says a rent was paid), the resource/endpoint (POST /api/v1/gerance/declaration-paiement), and the goal (trace the encaissement). It also distinguishes itself from sibling quittance_loyer by stating it must be called before it.

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?

Gives explicit when-to-use ('QUAND le client vous dit qu'un loyer a été payé'), sequencing relative to quittance_loyer, and a conditional routing rule ('Si extrait bancaire : source=extrait_bancaire'). It also sketches the resulting next action (quittance if complete, otherwise reçu).

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

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

With no annotations, the description carries the full burden and does so richly: it returns the full quote as HTML in the response, not as a file, URL, or PDF, and nothing is saved or sent to the client. It also clarifies that no order is placed at this stage. This is exactly the behavioral context an agent needs for a generation 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 text is dense but front-loaded with the key condition (QUAND), then output behavior, then the line format, then the next step. Every clause earns its place and nothing is wasted.

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?

Given no output schema and 11 parameters with full schema descriptions, the description completes the picture by explaining the return format (HTML in response, no file), the side-effect profile (nothing saved or sent), and the line-item shape. Nothing essential for correct invocation is missing.

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 would be 3. However, the description adds meaning beyond the schema by specifying the expected shape of each line item: lignes[] = {libelle, quantite, prix_unitaire, tva}, which the nested object schema does not define. This is useful for constructing the required array.

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 verb and resource: generating a works quote (devis) before client approval, and explicitly contrasts it with bon_intervention (nothing is ordered at this stage). It also names the follow-up tool facture_facturx once the quote is accepted. This lets an agent distinguish it from related siblings without checking schemas.

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?

It gives an explicit when: when an artisan prices works before client approval. It also states when-not and the alternative: nothing is ordered unlike bon_intervention, and after acceptance use facture_facturx. The routing logic is complete.

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

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

With no annotations, the description carries the full burden and does: it discloses the return medium (complete HTML in the response, not file/URL/PDF), the persistence behavior (nothing is saved, keep it yourself), and the downstream workflow (the ENTRÉE report is the one compared at exit). This is exactly the context an agent needs before invoking an unannotated 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?

Front-loaded with the usage trigger, then legal basis, return behavior, persistence caveat and field guidance in that order. Dense but every sentence carries distinct operational information; no filler.

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 14-parameter, output-schema-less, annotation-less tool, the description covers the return format, the no-persistence caveat, the entry/exit workflow and the critical nested inputs, which is sufficient for an agent to call it 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 description coverage is already 100%, so baseline is 3; the description adds value by prioritising the three nested arrays (pieces[], compteurs[], cles[]) and explaining that omitting a poste forfeits later deposit deductions — a consequence the schema descriptions do not convey.

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 and resource ('constater l'état du logement', 'état des lieux d'entrée ou de sortie') and even cites the governing decree (2016-382), making clear this is the condition-report generation tool and not one of the many unrelated contract/billing siblings (quittance_loyer, mandat_gerance, avenant_revision_irl).

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 trigger ('QUAND il faut constater l'état du logement, à l'entrée ou à la sortie'), the legal purpose (evidence to withhold from the deposit), and direct instructions to populate pieces[], compteurs[] and cles[] with the stated consequence of omission — nothing meaningful 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.

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

Aucune annotation n'étant fournie, la description assume pleinement la charge de transparence. Elle révèle des comportements utiles : aucune consommation d'unité, disponibilité hors fenêtre gratuite, absence de quota. Elle ne décrit pas en détail ce qui se passe après l'envoi, mais pour un outil de feedback simple, le niveau de transparence est correct.

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?

Le texte est court, les phrases vont à l'essentiel et l'information clé sur le déclenchement est placée en tête. Il existe une légère redondance entre « sans quota, toujours ouvert » et « n'utilise aucune unité, disponible même hors fenêtre gratuite », mais cela reste acceptable et l'ensemble est efficace.

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?

Pour un outil simple avec deux paramètres non imbriqués et sans schéma de sortie, la description couvre le déclenchement, la finalité et le coût d'utilisation. Il manque seulement une mention explicite du résultat après l'envoi, mais cela ne bloque pas un agent pour sélectionner et invoquer correctement l'outil.

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?

Le schéma couvre 100 % des paramètres, avec des descriptions déjà claires pour « message » et « context ». La description ajoute des exemples de contenu possible (outil, calcul, idée, bug), mais ne compense pas un manque du schéma. La note de base 3 est donc appropriée.

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?

La description utilise un verbe d'action spécifique (« Envoyer un retour / suggestion ») et identifie clairement la ressource concernée : l'application Synergieloc. Elle donne des exemples concrets (remarque sur un outil, calcul, idée de fonctionnalité, bug) et se distingue des outils frères, tous orientés métier, en étant le canal de feedback global.

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?

La description indique explicitement quand utiliser l'outil : « QUAND un résultat vous semble faux, incomplet, ou qu'un endpoint plante ». Elle précise aussi qu'il est gratuit, sans quota et toujours ouvert, ce qui guide le choix dans un contexte de consommation d'unités. Elle ne nomme cependant pas une alternative précise à préférer dans les autres cas, d'où un 4 plutôt qu'un 5.

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

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

With no annotations, the description carries the full burden and delivers: it discloses the exact return shape ({_mcp_pdf_base64, _mcp_mime}) and warns that the PDF arrives base64-encoded inside text and must be decoded before writing. It also states nothing is persisted or transmitted to the administration — critical behavioral facts an agent cannot infer elsewhere.

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?

Front-loads the trigger condition and is dense with useful content, but has mild redundancy (the Factur-X name is restated after the compliance kicker) and an embedded field list that sits awkwardly at the tail.

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 complex nested tool with no output schema and no annotations, the description covers the missing pieces: output encoding, no persistence, format semantics, and the trigger context. Nothing an agent needs to call it correctly is absent.

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%, so the baseline is 3, but the description adds value the schema lacks: it documents the nested lines[] fields (description, quantity, unit_price HT, vat_rate) which the schema leaves as an empty object, and clarifies format=preview ('PDF sans XML') — notably correcting the schema's enum description, which mismatches the actual enum values.

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 artifact (Factur-X invoice, PDF/A-3 + XML EN 16931) and the exact trigger (French e-invoicing compliance). It also actively distinguishes itself from siblings — 'le seul outil de ce serveur qui produise un vrai PDF ; tous les autres documents sortent en HTML' — so an agent can route without opening other schemas.

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 'QUAND' condition (invoice must comply with French e-invoicing / EN 16931) and then carves out the alternative case by noting every other document-producing tool emits HTML. Both the when and the when-not are stated.

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

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

With no annotations, the description carries the full burden. It usefully discloses the return medium (complete HTML in the response, not a file/URL/PDF) and the operating scope (local folder, no SaaS portal access) — real value. However, it says nothing about whether this creates/persists a record, permissions, or side effects, which matters for a 15-param generation 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?

Front-loaded with the QUAND trigger, then output contract and scope in compact form. Every sentence carries information; slightly dense but no filler.

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 no output schema, the description helpfully explains the return format (HTML in-response) and the before/after relationship to the sibling. Parameter detail is delegated to the schema, which is complete, so the definition is adequate overall.

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 schema already documents all 15 parameters thoroughly. The description adds no parameter-level semantics of its own, which is acceptable given full coverage — baseline 3.

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?

Identifies the resource precisely (fiche mission / chantier, app Missions) and frames it as the pre-intervention document, explicitly contrasting it with compte_rendu_chantier (before vs after). The action verb is only implied ('Fiche mission'), but 'Renvoie la fiche en HTML complet' clarifies the output. An agent can distinguish it from most siblings.

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?

Front-loaded 'QUAND un artisan prépare une intervention ou un chantier' gives the trigger condition, and it names a sibling (compte_rendu_chantier) with the temporal rule that selects between them. No explicit when-not conditions beyond that, but the routing is clear.

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

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

No annotations, so the description carries the burden. It discloses statelessness, output formats (JSON/PDF), and envelope address behavior, but does not clarify whether the tool persists documents, has side effects, or only returns a response.

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?

Description is compact and front-loaded with the use case, but contains redundancy (INDICATIF/À titre indicatif) and mixes technical endpoint details with tax context, slightly reducing conciseness.

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?

No output schema means the description should clarify the return value. It mentions JSON/PDF formats and 'synthèse', but not the actual JSON structure or what comparison data is included, leaving response expectations partly underspecified.

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 already covers 100% of parameters with detailed unit/scope descriptions. The description reinforces the key recettes_brutes + charges_deductibles inputs and adds relevant tax context (30% allowance, 15k threshold), improving semantic clarity beyond the schema.

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?

Description clearly defines when to use the tool (landlord comparing micro-foncier vs réel before tax filing) and its core function of comparing regimes. However, it doesn't explicitly state whether the primary output is a calculated comparison or a generated document, leaving slight ambiguity.

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?

Starts with 'QUAND' and gives a precise trigger scenario, plus exclusions (not tax advice or filing, refer to professional). It doesn't name sibling alternatives, but the when/not-when guidance is sufficient for tool selection.

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

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

Without annotations, the description carries the burden. It discloses that it is free and no key is required, and implies a read operation. However, it does not mention potential errors or limitations (e.g., invalid slug behavior), leaving some uncertainty.

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 two sentences, front-loaded with the condition and action, and includes essential cost/auth info. No redundant words.

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 simple read operation, the description covers the trigger, action, output format, and auth requirements. It does not mention error handling, but given the simplicity and lack of output schema, it is sufficiently complete.

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 for the slug parameter already provides examples and covers semantics (100% coverage). The tool description adds the note that the slug is obtained via guides_liste, which adds contextual meaning beyond the schema.

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 clearly states it reads a full official guide in Markdown given a slug, and specifies the trigger condition (when guides_liste has returned a slug). It is specific and unambiguous.

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?

It explicitly states when to use it (after guides_liste returns a slug) and notes that it is free and requires no key. It does not explicitly mention alternatives, but the conditional 'QUAND' provides adequate usage context.

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

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

With no annotations, the description carries the transparency burden. It adds useful behavioral context: the call is free, requires no unit or key, and only lists guides rather than performing an operation. It does not describe the exact output format, but for a zero-parameter listing operation this is a minor omission.

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 compact two-sentence structure: when to use it, what it lists, and invocation cost. The when-condition is front-loaded, and the examples of guide topics add value without bloat.

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 zero-parameter, no-output-schema tool, the description is complete: it gives the trigger situation, the content scope, and the absence of any unit/key requirement. There are no hidden prerequisites or parameters an agent could miss.

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?

There are zero parameters, so the baseline is 4 and there is nothing for the description to clarify. The explicit statement that no unit or key is required reinforces that the agent does not need to supply any hidden invocation material.

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 resource: 'Liste les guides officiels du logiciel Synergieloc.' It also enumerates the guide contents (screen-by-screen manual, French legal rules) and implicitly distinguishes itself from sibling operation tools like quittance_loyer or irl_revision_loyer by being a meta-guide listing tool.

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?

It opens with an explicit when-to-use condition: 'QUAND vous ignorez comment une opération se fait... ou quelle règle métier s'applique.' This clearly tells an agent to consult this tool for how-to or business-rule questions. It does not name explicit alternatives or exclusions, but the trigger condition is strong enough to route correctly among the operation-focused siblings.

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

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

With no annotations, the description carries the behavioral burden. It discloses the output ('Renvoie le nouveau loyer plafonné, la formule et les avertissements légaux') and the legal basis, which is useful. However, it does not explicitly say that the tool only calculates and does not modify the lease or generate a document, which is important given the sibling 'avenant_revision_irl'.

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 compact and well organized: when to use, what it does, what to provide, and what it returns. Every sentence carries distinct information, with no filler or redundant restatement of the tool name.

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 calculation tool with no output schema, the description adequately explains the inputs and the returned items: new capped rent, formula, and legal warnings. It is nearly complete, but an explicit note that it does not create the revision avenant would fully close the 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?

Schema coverage is 100%, so the schema already documents every parameter. The description repeated the core inputs ('loyer actuel et les deux indices IRL') but adds little semantic value beyond what the schema provides, and it does not clarify the role of the optional 'charges_actuelles' parameter.

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 clearly identifies the operation: 'Révision annuelle d'un loyer d'habitation indexée sur l'IRL' with a legal reference. It is specific enough to distinguish from most sibling tools, but it does not explicitly differentiate itself from 'avenant_revision_irl', even though the return value suggests calculation rather than document generation.

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 opens with an explicit trigger condition: 'QUAND un bail arrive à sa date anniversaire et que le loyer peut être révisé.' It also states the required inputs: 'Fournir le loyer actuel et les deux indices IRL (INSEE).' However, it does not mention when to prefer a sibling tool such as avenant_revision_irl instead.

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

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

With no annotations, the description carries the burden and discloses the key behavioral trait: the log is returned as full HTML in the response — no file, no URL, no PDF. It also notes the default taux_km behavior. It does not state auth/permission needs, persistence, or side effects, so it is strong but not exhaustive.

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?

Dense but well ordered: routing condition first, then purpose, then output contract, then parameter notes. There is minor redundancy in "ni fichier, ni URL, ni PDF," but every sentence carries information and nothing is buried.

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 and no annotations, the description supplies the most needed missing piece (return format = HTML in the response) along with params and the sibling alternative. It stops short of describing what the HTML contains or whether anything is stored server-side.

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%, so the baseline is 3, but the description adds meaning the schema lacks: the trajets[] element shape {date, depart, arrivee, km, motif} (the schema only types items as a bare object) and the optionality/default of taux_km. This goes beyond the structured fields.

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 verb and resource — generates a mileage log plus indemnities ("Journal kilométrique + indemnités") — and explicitly names the sibling it is not ("pour des frais réels sur justificatif, c'est note_frais"). An agent can distinguish this from note_frais without opening either schema.

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?

It front-loads the trigger condition ("QUAND les déplacements doivent être justifiés au BARÈME kilométrique") and gives the explicit exclusion + alternative (frais réels sur justificatif → note_frais). Both when-to-use and when-not-to-use are covered with no inference required.

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

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

With no annotations, the description carries the burden and does well: it declares the output is complete HTML in the response, explicitly not a file, URL or PDF, and that 'aucune commande n'est passée' — a crucial non-mutating clarification for a purchase-list tool. It stops short of stating any permission or authentication requirements, so it is strong but not exhaustive.

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?

Front-loaded with the routing condition, then alternatives, then return format, then item shape — every clause earns its place and there is no filler or restatement of the name.

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?

There is no output schema and no annotations, so the description must cover both — and it does, specifying the return medium (HTML in-response) and the absence of side effects. Combined with a fully described input schema, an agent has everything needed to call this 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 description coverage is 100%, so the seven parameters are already documented and the baseline is 3. The description adds the articles[] shape ({libelle, quantite, unite, prix}), but this conflicts with the schema's own wording ('désignation, quantité, unité, référence fournisseur'), so the added value is partial rather than additive.

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 and resource ('préparer les ACHATS d'un chantier', la liste emportée chez le fournisseur) and explicitly contrasts it with the sibling devis_travaux ('pas un chiffrage client'). An agent can separate this from the quote tool and from cao_metres without opening any schema.

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?

Gives explicit when-to-use framing ('QUAND il faut préparer les ACHATS'), names the alternative for the wrong case (devis_travaux for client pricing), and names the upstream tool (cao_metres) that computes quantities to feed back in. Routing is fully determined.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the return artifact (complete HTML in the response, explicitly not a file, URL, or PDF), and critically that Synergieloc MCP does NOT persist the mandate to the database, so the agent must handle signing and local storage. This is exactly the non-obvious behavioral context an agent needs.

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?

Front-loaded around the 'QUAND' trigger, then output behavior, then downstream handling. Every sentence carries substantive information (legal basis, output format, persistence, envelope). Slightly dense with several clauses chained, but no filler.

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 16-parameter, no-annotation, no-output-schema tool, the description supplies the key missing pieces: output format (HTML in response) and the fact that nothing is stored server-side. Legal context (loi Hoguet cap on duration, carte professionnelle) is echoed from the schema. Nothing critical is missing, though the signing/storage workflow could be marginally more explicit.

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 all 16 parameters are already documented in-schema. The description adds a useful detail about proprietaire_adresse driving the window-envelope block, but does not otherwise extend parameter meaning. Baseline 3 is appropriate.

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 ('Rédige') and resource ('MANDAT DE GESTION (loi Hoguet)') and frames it precisely as 'le contrat de départ, avant tout le reste', which distinguishes it from the many downstream document siblings (avenant, quittance, relance). An agent can identify the tool's role without opening the schema.

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 trigger condition ('QUAND un propriétaire confie la gestion de son bien à une agence') and clarifies ordering ('avant tout le reste'). It also redirects 'Démarchage' to a different endpoint, though that target is not a sibling tool. Clear context, but no explicit exclusions against sibling documents.

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

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

With no annotations, the description carries the full behavioral burden and does well on the crucial point: it explicitly says the full HTML document is returned in the response, that no file/URL/PDF is produced, and that nothing is saved. That disclosure of output form and persistence is genuinely valuable. It omits auth/permission requirements and any side-effect caveats, keeping it short of a 5.

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?

Four sentences, front-loaded with the usage trigger and the output-format constraint, so nothing important is buried. The first and second sentences overlap somewhat, both restating the entrée/sortie checklist + solde combination, which is minor redundancy rather than waste.

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 13-parameter, no-output-schema, no-annotation generation tool, the description adequately covers what the tool returns and that nothing is persisted. Parameter-level detail is left to the schema, which is complete, so overall the agent has what it needs, minus sibling disambiguation.

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 schema already documents all 13 parameters in detail. The description notes that `type` (entree|sortie) selects the printed sections, but the schema states the same thing ('Il détermine les rubriques imprimées'), so this adds no meaning beyond structured data. Baseline 3 applies.

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 action and deliverable: a tenant ENTRÉE/SORTIE document combining a checklist and a solde de tout compte, generated for either direction. The inclusion of 'solde de tout compte' helps distinguish it from a plain inventory, but it never names or contrasts with the close sibling edl_etat_des_lieux, so the agent must infer the boundary itself.

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 front-loaded 'QUAND un locataire ENTRE ou SORT du logement' gives a clear triggering context for use. However, it offers no exclusions or alternatives, notably failing to say when to prefer edl_etat_des_lieux over this tool, which is exactly the ambiguity an agent faces here.

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

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

With no annotations, the description carries the behavioral burden and does so well: it discloses that the output is full HTML returned inline (no file, URL, or PDF) and explicitly states that no reimbursement is triggered, which is a critical side-effect disclaimer for a tool named around reimbursement. It stops short of covering auth/permission requirements, so it is not fully complete.

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?

Dense but front-loaded, leading with the conditional trigger before the app name, output format, side-effect disclaimer, and payload shape. Every clause carries information, though the single long sentence is somewhat crowded rather than crisply segmented.

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?

There is no output schema, so the description properly explains the return value (full HTML in the response, no file/URL/PDF) and the side-effect status (no reimbursement triggered). Combined with the parameter payload hint, an agent has everything needed to call it 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 already 100%, but the description adds genuine value beyond it: the nested lignes items are typed only as a bare 'object' in the schema, while the description enumerates the expected fields ({date, libelle, montant, mission, justificatif}), going beyond the schema's own prose of date/nature/montant TTC/justificatif.

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 action and resource (generating a note de frais) and immediately distinguishes itself from the sibling journal_kilometrique by contrasting receipts-based actual expenses with the mileage scale. An agent can tell what this tool does and does not do without opening the schema.

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 'QUAND' trigger (expenses to be reimbursed or justified) and names the alternative tool along with the exact condition that selects it (dépenses réelles sur justificatif vs barème kilométrique). Both the when and the when-not-to-use are given.

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

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

Aucune annotation n'est fournie, mais la description précise que l'outil est gratuit, instantané, sans email requis, et qu'il fournit une clé. Elle ne mentionne pas explicitement les effets secondaires (ex. création d'une entrée persistante), mais reste globalement transparente sur le comportement.

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?

La description est très verbeuse, répète plusieurs fois les mêmes informations (gratuit, instantané, 30 jours, 240 min/jour, IP) et utilise des majuscules et des énumérations redondantes. Elle aurait pu être condensée en deux phrases claires.

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?

La description donne suffisamment de contexte pour qu'un agent sache quand appeler l'outil, ce qu'il obtiendra et pourquoi il est utile. L'absence de schéma de sortie est compensée par des indications explicites sur le résultat (clé API gratuite).

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?

Le schéma couvre 100% des paramètres (name, email) avec des descriptions en français. La description ajoute que 'name' sert à retrouver/gérer la clé et que 'email' est optionnel pour recevoir une copie, ce qui enrichit le sens au-delà du simple type.

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?

La description indique clairement l'action (obtenir une clé API), la ressource concernée (clé API gratuite) et le moment d'utilisation (avant tout autre outil payant). Elle distingue bien cet outil des outils payants comme quittance_loyer et regularisation_charges.

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?

La description donne une directive explicite : « APPELEZ-LE EN PREMIER » quand on n'a pas encore de clé, et précise qu'aucun email n'est requis. Cela fournit un critère de sélection clair parmi les outils frères.

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

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

The description discloses that it is a free catalogue with no API requirement and provides a REST endpoint. It does not explicitly state that it is read-only, but the nature of a catalogue and the GET method imply no side effects, which is sufficient given the absence of 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 concise, containing all relevant information in a single sentence, though the leading 'WHEN' is stylistically unusual. It is well-structured with a clear trigger, definition, and endpoint.

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?

Given the tool's simplicity with no parameters or output schema, the description provides enough context for an agent to know when and how to use it. It clearly differentiates from the many sibling tools.

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?

The schema has no parameters, and the description mentions '0 units' and 'no API', which is consistent. With zero parameters, the baseline is 4, and the description provides adequate context.

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 clearly states that the tool provides a catalogue of Partner Portal apps mapped to MCP tools, with an explicit verb and resource. It distinguishes itself from sibling tools by being a discovery/catalogue endpoint.

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?

It explicitly says to call it first when helping an artisan or BTP company to know what the Partner Portal covers, giving a clear trigger condition. It also notes that no API key is required, which adds usage context.

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