immobilier

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

Annotations already declare readOnlyHint/destructiveHint/openWorldHint, and the description adds genuinely non-derivable behavior: the output is a draft only, no listing is ever published through MCP, publication is reserved for the Synergieloc operator via manual validation, and publier=true is rejected. It also cites the backing REST route, which helps the agent understand the call's scope.

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 trigger condition, then the action, then the critical constraint. Slight redundancy between 'aucune publication sur synergieloc.fr via MCP' and 'publier=true est refusé', though the emphasis is defensible for a constraint that must not be missed. Four sentences, 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?

With 14 optional parameters and no output schema, the description compensates by naming the return shape (texte_brut + html) and by explaining the statut='brouillon' constraint that governs the whole call. Nothing needed to invoke 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 description coverage is 100% across all 14 parameters, and those descriptions already carry the substantive semantics (DPE classes A-G with F/G restrictions, loyer hors charges with rent-control caveat, statut fixed to 'brouillon'). The description adds no per-parameter meaning beyond what the schema provides, 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 verb and resource ('Rédige un BROUILLON d'annonce de location') plus the exact output form (texte_brut + html). It also draws a sharp line between drafting and publishing, so an agent can tell it apart from any diffusion/publishing path in the sibling set (mandat_gerance, candidature_locataire).

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 bien vacant doit être mis en location et qu'il faut rédiger l'annonce') and an explicit exclusion (no publication via MCP, publier=true refused). It does not name a sibling alternative, but the when-to-use and when-not-to-use conditions are both stated directly.

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/openWorldHint=false, but the description adds real traits beyond them: HTML printable output with PDF via a specific API endpoint, mandatory window-envelope layout (recipient right), and a hard guard-rail that a 5-digit postal code is required. The 'Calcule et notifie' wording is slightly ambiguous versus the read-only hint, though 'prêt à envoyer' clarifies it only drafts.

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 with 'QUAND', but is fragmentary and densely ALL-CAPS, and 'Calcule et notifie le nouveau loyer' largely repeats the earlier 'Courrier de révision ... prêt à envoyer' sentence. Information-dense but with redundancy and noisy emphasis.

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, no-output-schema tool, the description covers the trigger, the prerequisite sibling, the output artifact (printable HTML/PDF), the envelope-layout constraint, address semantics and a validation guard-rail. Little an agent needs to call it correctly is missing, aside from explicit confirmation that nothing is sent.

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 interpretation the schema does not: prefer locataire_adresse (postal) over logement_adresse (the property), and the 5-digit postal-code constraint for the recipient address. That is meaningful guidance on parameter choice and validation.

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: drafting the IRL rent-revision letter/amendment ready to send to the tenant, and explicitly contrasts it with the sibling irl_revision_loyer that only computes. An agent can distinguish this from the compute sibling 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 a 'QUAND' clause defining the trigger condition (IRL revision already calculated and must be notified by mail) and names the prerequisite alternative ('Calculez d'abord avec irl_revision_loyer'). Both when-to-use and the ordering vs the sibling are explicit.

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 and destructiveHint=false, and the description confirms and enriches this: output is full HTML in the response, no file/URL/PDF, 'rien n'est enregistré ni envoyé'. That output-format and no-persistence detail is real value beyond the annotations, though error cases and input validation behavior are not covered.

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 useful scoping information is front-loaded, but roughly a third of the text is promotional ('Service VENDU AUX AGENTS IA... Proposez au client final de souscrire... plan Agent 49,99€/mois'), which does not help tool selection and dilutes the signal.

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 no output schema, the description usefully states the return format (HTML in the response), that nothing is persisted or sent, and that no park access is needed. That is sufficient to call the tool correctly, with only minor gaps around failure behavior.

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% across all 15 parameters, so the schema already documents IBAN, loyer, charges, dates, etc. The description adds only the window-envelope hint for recipient placement, which the schema itself also states. With the schema doing the heavy lifting, 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 verb and resource ('Génère un AVIS D'ÉCHÉANCE') and explicitly contrasts the goal with the sibling quittance_loyer ('atteste l'encaissement APRÈS coup'). An agent can distinguish this from every other billing sibling without opening a 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 an explicit trigger ('QUAND le bailleur doit APPELER le loyer du mois, AVANT paiement') and names the alternative tool with the discriminating condition (before vs after payment). When-to-use and when-not-to-use are both 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 readOnlyHint=true, destructiveHint=false, openWorldHint=false, but the description adds substantial context beyond them: the letter is returned as full HTML in the response with no file, URL or PDF, nothing is persisted server-side, and no message is dispatched to the provider. These operational facts directly shape how an agent must handle the output.

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 trigger, then disambiguation, then return-format and side-effect facts. Four dense sentences with no filler; the ordering matches the decisions an agent makes.

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, so the description carries the return contract itself (HTML in the response, no download) and the side-effect contract (nothing saved, nothing sent). For a 12-param drafting tool with a safe read-only profile, nothing an agent needs before calling 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 each of the 12 parameters is already documented in the schema. The description adds no parameter-level syntax or constraint beyond that, 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 and artifact ('le bon de commande qui engage la dépense') and immediately contrasts it with two named siblings, devis_travaux and compte_rendu_chantier. An agent can select this over those alternatives 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... ou signalée au propriétaire') and gives the disambiguating condition for each sibling: devis_travaux = asking a price, nothing ordered; compte_rendu_chantier = reporting after the fact. When-to-use and when-not are both 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 cover the safety profile (readOnly, non-destructive, closed-world), and the description still adds valuable context: free, no API key, 0 units, public rules only, server-side guardrails remain authoritative, and the exact return shape. It stops short of describing versioning semantics or refresh behavior, so not 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?

Front-loaded with the WHEN directive and information-dense throughout; every clause carries content. It is a packed run-on spanning several ideas, which slightly hurts scanability but wastes no 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?

No output schema exists, and the description compensates by outlining the returned object structure and the domains covered. For a single-optional-parameter read tool with full annotations, nothing an agent needs to invoke 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% and the enum already enumerates all domains, including the 'omit to receive all domains' behavior that the description repeats. The description adds no filter syntax or semantics beyond what the schema documents, 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 (read a versioned playbook of best practices) and the exact resource, plus what it contains (public MCP/API rules, no tenant data). It is immediately distinguishable from every sibling, which are all task-specific domain tools rather than meta-guidance.

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 invocation timing: call it FIRST on server discovery, and again if cached instructions may be stale. That is a clear when-to-use trigger that no other sibling provides, and it implicitly excludes routine data operations.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds genuinely useful behavior beyond that: the PDF retrieval route and the instruction to file the result locally ("À classer dans le dossier local après réception"). It does not mention auth, quotas, or error behavior, so it stays at a solid 3.

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 short telegraphic fragments with the usage trigger front-loaded and no filler. It is appropriately sized, though the fragmentary, clipped style slightly reduces readability and structure compared to full sentences.

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 tool with no output schema, the description does give the output format and destination, which is the main missing piece. It still omits what the caller receives concretely, where the HTML is written, and any permission or prerequisite context for generating the dossier.

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% across all 17 parameters, including the notable caveat that pieces_jointes carries labels only, not documents. The description adds nothing about parameters, so the baseline 3 applies — the schema does all the explanatory work.

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 identifies the artifact produced ("Dossier de CANDIDATURE locataire") and its formats (HTML, PDF via /api/v1/documents/candidature), but never states the action verb — it is left implicit that the tool generates the dossier. A reader must infer the operation from the artifact name rather than from an explicit verb+resource pairing.

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 candidat constitue son dossier pour un logement" gives a clear situational trigger for invocation. However, it names no alternative tool and states no when-not conditions, so routing among the many sibling document tools is still 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?

Annotations already cover read-only, non-destructive, closed-world, so the safety profile is settled. The description adds real output behavior: one step per trade with dates, SVG axonometric and ground-floor plan per step, and the optional single-date state — valuable since there is no output schema.

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?

A single dense paragraph, front-loaded with the WHEN trigger and the 4D framing before the trade vocabulary and return description. Slightly run-on but every clause carries information about output structure or classification.

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, all-optional, no-output-schema tool, the description supplies the missing return-value picture (per-trade steps, dates, two SVG views, single-date state). The input scene schema is inherited and well documented elsewhere, so little is left unexplained.

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 15 scene parameters are already fully documented in the schema, which sets the baseline at 3. The description adds domain framing (trade classification, schedule derived from model quantities) but no parameter-level detail 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?

States a specific verb and resource ('show the model as built at a date') and pins the semantics precisely with '4D, as Navisworks links a model to a schedule'. It is clearly the only scheduling/sequencing sibling among the cao_* export tools, though it never names an alternative 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?

Opens with an explicit trigger ('WHEN the building must be shown AS IT WILL BE BUILT over time'), which is a clear usage context an agent can match. It offers no when-not guidance or named alternatives (e.g. cao_permis, cao_pdf) for overlapping use 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description goes further, disclosing selection semantics (IFC GlobalId, camera in front) and the return payload {topics, conflits, alertes, bcf_base64} with the instruction to write bcf_base64 to a .bcfzip file — useful context 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-loads the trigger condition and packs topic granularity plus return shape into a few dense sentences with no filler. Slightly long, but every clause (readers, topic type, GlobalId, camera, return keys) earns its place for a format-critical export.

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, but the description compensates by naming the returned keys and telling the agent how to persist bcf_base64. Combined with 100% schema coverage and clear read-only annotations, an agent has enough to invoke 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?

With 13 parameters at 100% schema description coverage, the schema already carries the detail. The description adds only the high-level 'pass a scene or ifc' branch, which is largely already stated in the ifc parameter description ('When given, scene fields are ignored'). 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 verb (export) plus resource (clashes and issues) and output format (BCF 2.1 zip), and explains the granularity (one Clash topic per clash, one Issue topic per alert). This clearly separates it from siblings like cao_conflits_ifc or cao_generer_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 leading 'WHEN clashes and control alerts must leave as a BCF 2.1 zip readable in Solibri/BIMcollab/Navisworks/Revit/Archicad' gives a concrete trigger condition. It lacks an explicit 'instead use X' routing to siblings such as cao_conflits_ifc, so it stops short of 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 readOnlyHint=false already flagged, the description adds real behavioral context: enregistrer creates a new version only when the definition changed ('unchanged definition: no new version'), which explains the idempotentHint, and lister anonymizes other users' families behind an 'anonymous author code', a privacy behavior not visible in annotations. It still says nothing about permissions, quotas, or failure modes.

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 trigger condition is front-loaded and every clause carries information (per-action behavior, the prerequisite tool), with no filler. It is dense and slightly crammed into two long sentences, which costs a point against a tighter, better-segmented layout.

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 6-parameter, multi-action tool with one nested object and no output schema, the description covers all three actions, the nested `famille` payload's purpose, and the required prerequisite step. It does not describe what lister or lire actually return beyond the families themselves, leaving some return-shape ambiguity.

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% and each parameter already documents the action it applies to (lire, enregistrer), so the schema carries the load. The description mostly restates those action-to-parameter mappings ('publique' to share, 'version' default latest) rather than adding syntax or format detail, 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 names the specific resource (the account's persistent family library) and enumerates its three modes (lister/lire/enregistrer) with a helpful Revit-family-library analogy. It clearly differentiates itself from cao_famille_essayer, but it does not distinguish itself from the closely named siblings cao_familles and cao_familles_recharger, which an agent would need to tell 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 ('WHEN a parametric family ... must be reused across projects or shared') and states the prerequisite workflow ('Build and test the family first with cao_famille_essayer'). There is no guidance on when NOT to use it versus the sibling library tools, so it falls 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?

Annotations already declare readOnlyHint/destructiveHint/openWorldHint, so the safety profile is covered; the description adds what each mode actually computes (quantitatif x taux unitaires, cost cumulated over time, cash-flow synthesis) and the default branch. The trailing 'Lecture seule' merely restates the readOnlyHint, but the mode-level behavior info is genuinely additive.

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?

A single dense sentence that front-loads the trigger condition and then branches through the three actions with their parameters. Nothing is wasted, though the colon-chained structure is heavy and the redundant 'Lecture seule' tail could be dropped.

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 usefully characterizes what each action returns; safety is covered by annotations and all four parameters are schema-documented. Remaining gap is the nested 'scene' object, whose expected structure is only hinted at ('murs, boites, ouvertures...') in neither description nor schema detail.

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% and the schema already documents action, phase, and debut, including defaults. The description adds only marginal semantics (that phase filters tasks by BEP stage), so the baseline 3 holds; the 'scene' nested object's expected contents remain equally thin in both places.

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 ('estimer le cout (5D) et le planning de construction (4D) d'une scene CAO') and enumerates the three distinct output modes. It does not name or rule out the closely-named siblings (cao_4d, cao_bim_4d_cpm, cao_bim_planning_cpm), so the agent still has to infer the boundary.

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?

'Appelez quand vous devez estimer...' gives an explicit invocation trigger, and each action branch is tied to the situation it serves (bilan = filtered tasks, courbe_s = cumulative S-curve, tresorerie = cash flow). Missing is any statement of when NOT to use it or which sibling tool handles adjacent costing/planning requests.

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, destructiveHint=false and openWorldHint=false, and the description is consistent ("Lecture seule"). It adds real behavioral context beyond annotations: the 5D cost split by lot weights, day-by-day cumulative output in ISO dates, and the cash-flow derivation (30% deposit, monthly billing, 5% retention). It does not mention limits or caveats beyond "Indicatif".

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 purpose is front-loaded in the opening clause, and every clause carries information, but the whole description is one overloaded colon-and-parenthesis sentence mixing purpose, computation weights, output format, mode selection and prerequisites. Abbreviations (ES/EF, CPM, 5D) go unexplained, which slows parsing.

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, but the description compensates by describing the returned data (day-by-day cumulative curve in ISO dates, monthly treasury), and the nested scene object is documented in the schema. Adequate for a read-only computation tool, though it never clarifies how the scene geometry feeds the CPM beyond "taches_personnalisees optionnelles".

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 still adds value by stating that "debut" is required even though the schema lists no required parameters, and by explaining how "action" switches between the curve and treasury outputs, which the schema only lists as enum strings.

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: produces the S-curve dated by the critical path (4D schedule) plus the monthly cash flow of a scene. The scope is precise enough to separate it from generic siblings like cao_bim_4d5d or cao_bim_planning_cpm, though it never names an alternative 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?

"Appelez quand vous voulez la COURBE EN S DATEES" gives a clear trigger, and "action=courbe (defaut) | tresorerie" tells the agent how to pick the output mode. "debut ISO requis" flags a prerequisite. No exclusion or when-not guidance is given against the many similar BIM 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?

Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false, and the description aligns by saying Lecture seule. Beyond the annotations, it adds a meaningful behavioral caveat: the result is Indicatif and CCTP plus signed ERP regulations prevail. It does not describe the return structure, but the annotations carry the safety profile.

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-loads the call condition and component list. However, it repeats the schema almost verbatim for scene and repeats the read-only annotation, so not every phrase adds new 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?

For a one-parameter, read-only verification tool with full schema coverage and no output schema, the description gives enough context to select and invoke it correctly. The main remaining gap is that it does not explain what the verification returns, but the component list and indicative caveat make the definition broadly 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 coverage is 100%, and the single scene parameter is already documented as abri_bus {structure, assise, eclairage, toiture}. The description repeats the same nested component list without adding format details, validation rules, or other semantics 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 verb, VERIFIER, and a specific resource, L'ABRI BUS / abri voyageurs, then enumerates the checked components: structure, assise, eclairage, toiture. This is clearly distinct from the many generic cao_bim siblings and from abris_jardin.

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 the tool when you need to verify a bus shelter, which gives a clear usage condition. It adds the important caveat that the check is indicative and that signed CCTP/ERP rules prevail, but it does not mention when not to use it or name an alternative sibling.

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 cover the safety profile (readOnlyHint=true, destructiveHint=false), so 'Lecture seule' adds nothing, but 'Indicatif — CCTP et note de calcul signes priments' is a genuine disclosure beyond structured data: it warns the agent that the output is non-authoritative and must not override signed documents. Return format and behavior on a missing 'abris_jardin' node remain unstated.

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 invocation trigger, then the check domains, then the parameter, then the caveat—good ordering with no filler. Slight waste from restating the schema's parameter definition, but overall dense and readable.

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 read-only, single-parameter indicative check with no output schema, the definition covers what is verified, the input shape, and the authority caveat. It does not describe what the check returns (pass/fail per AJ code, list of findings), which is the one real gap given there is no output schema to lean on.

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 the single 'scene' parameter. The description restates 'scene : abris_jardin {structure, ancrage, couverture, acces}' almost verbatim from the schema, adding no new syntax, optionality, or format 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 (VERIFIER) and a specific resource (ABRIS DE JARDIN / annexes legeres), then enumerates the four checked domains with their codes (AJ-STRUCTURE, AJ-ANCRAGE, AJ-COUVERTURE, AJ-ACCES). The topic is narrow enough to be distinguishable from generic siblings like cao_bim_structure or cao_bim_couverture, but the description never explicitly contrasts itself with those overlapping 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?

'Appelez quand vous devez VERIFIER LES ABRIS DE JARDIN' gives an explicit invocation trigger. The 'Indicatif — CCTP et note de calcul signes priment' line adds a precedence rule that tells the agent when this result should yield to other sources. No named alternatives or exclusions, though, 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?

Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so the safety profile is covered; the closing "Indicatif. Lecture seule." adds that the verdict is indicative rather than normative — a genuinely useful expectation-setter. It also names the regulatory basis applied, which explains what the audit encodes.

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 trigger condition, then the rule set, then parameter values and the read-only note. The dense threshold enumeration is long but each item evidences a rule the tool applies; it could be tightened without losing selection 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?

For a tool with a nested scene object (100% schema coverage) and no output schema, the description gives enough domain rules to know what the audit checks and that the answer is indicative. It stops short of describing the shape of the audit result (per-criterion findings vs. a single verdict/score).

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% and both parameters are documented in-schema, so the baseline is 3. The description repeats the type_batiment values (erp default | iop | habitation) and hints that thresholds vary by type (0,90 m vs 0,83 m habitation), but never explicitly maps which parameter drives which building-type exception.

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: auditing the PMR (disabled-access) compliance of a building scene, and even enumerates the concrete criteria checked (door widths, ramp slopes, parking ratio, arrêté du 20 avril 2017). This clearly separates it from generic siblings like cao_bim_conformite or cao_bim_reglementations, though no sibling is named 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?

"Appelez quand vous devez auditer l'ACCESSIBILITE PMR d'une scene (ERP, bureaux ou habitation ADAP)" gives an explicit triggering condition and the building types in scope. There is no when-not guidance or named alternative for adjacent checks (fire safety, acoustics, general conformity).

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 cover the safety profile (readOnly, non-destructive, closed-world), yet the description adds real behavioral substance: isolation is estimated by the mass law from declared layers plus a lateral-transmission margin, floor coverings discount impact noise (moquette 25 dB, parquet flottant 20 dB), and the result is explicitly indicative. 'Lecture seule' merely restates the annotation, but the method disclosure is valuable.

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 paragraph, front-loaded with the call trigger, followed by thresholds, the estimation method and the caveat. Every clause carries information; nothing is repeated except the harmless 'Lecture seule'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by stating exactly which quantities are checked and against which limits, so the agent understands the verdict criteria. It does not describe the returned structure or which of the four checks get reported when data is missing, which is the remaining 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 baseline is 3, but the description goes further by tying the nested fields to the computation: layers as (matériau + épaisseur_mm) drive the mass-law estimate, and the revêtement field is given concrete acoustic values. That tells an agent what to populate, not just what the shape is.

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: 'vérifier l'ACOUSTIQUE d'une scène contre la NRA (arrêté 30/06/1999)', and enumerates the four checks (bruits aériens, chocs, équipements, façades) with numeric thresholds. This is unmistakably distinct from siblings like cao_bim_incendie, cao_bim_conformite or cao_bim_cvc.

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?

'Appelez quand vous devez vérifier l'ACOUSTIQUE...' gives an explicit trigger condition, and 'Indicatif — l'isolement réel se mesure in situ' sets the boundary of when the result is authoritative. It does not name a substitute tool for cases where an indicative estimate is insufficient, so no alternative is offered.

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 read-only, closed-world, non-destructive. The description adds genuinely new context the annotations cannot: the result is 'indicatif' and signed DTU 20.12 / waterproofing notes take precedence. It also enumerates the four check identifiers (AC-HAUTEUR, AC-COUVERTINE, AC-ISOLATION, AC-RELEVE) that shape the output. The trailing 'Lecture seule' merely restates readOnlyHint.

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 trigger, then standards, then criteria, then data shape, then caveat — a logical reading order for an agent. Dense but every clause carries content; only 'Lecture seule' is redundant against the annotations.

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?

One optional nested parameter, no output schema — the description supplies the check codes, the numeric thresholds, the input shape and the reliability caveat, which is enough to call it and interpret results. Missing only an explicit statement of what the response contains per parapet (pass/fail vs measured value).

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 baseline is 3, but the description goes further by tying scene fields to acceptance criteria — hauteur_mm against a 150 mm threshold, releve_etancheite_mm against 150 mm, couvertine and isolation_continue as booleans to verify. That adds threshold meaning the schema alone does not carry.

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?

Specific verb + resource: 'VERIFIER LES ACROTERES de toiture-terrasse' with the applicable standards (DTU 20.12/43.1) and the four control points named. An agent can tell this apart from the broader cao_bim_etancheite or cao_bim_toiture_terrasse by scope, though no sibling is named 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?

Opens with an explicit trigger: 'Appelez quand vous devez VERIFIER LES ACROTERES'. The domain (roof parapets on a flat roof) is clearly stated as the condition for use, but no when-not condition or named alternative sibling is 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?

Annotations already declare readOnlyHint/destructiveHint/openWorldHint, and 'Lecture seule' merely restates that. The description earns credit for adding the reliability caveat (results are indicative, real FDES required for regulatory study) and clarifying what each action mode produces, which goes 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 the trigger and dense with useful detail; separators (| and : ) make it scannable. It runs long as a single stream, but nearly every clause carries information an agent needs.

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 5 params, a nested scene object and no output schema, the description carries the return burden and does so by naming the outputs (total, ratio kgCO2e/m2 vs RE2020 thresholds). Return shape for verifier/suggestions modes is only partly implied.

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 baseline is 3, but the description adds genuine meaning: it explains what action=verifier (verdict indicatif) and action=suggestions (substitutions et carbone evite) do, which the schema lists only as bare values, and it enumerates what the scene object contains.

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 (estimer) and resource (le carbone/ACV d'une scene), and details the computation method (quantites x facteurs FDES/INIES, total + ratio kgCO2e/m2). It does not explicitly distinguish itself from closely-named siblings like cao_re2020 or cao_energie, so an agent must infer the embodied-vs-operational distinction 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?

'Appelez quand vous devez estimer le CARBONE de la construction' gives a clear triggering condition, and the 'Indicatif — l'etude reglementaire exige les FDES reelles' caveat signals a boundary. No alternative sibling is named, so the agent has context but no explicit 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?

Annotations already declare readOnlyHint/destructiveHint=false/openWorldHint=false, so "Lecture seule" is largely redundant. The description's real contribution is the caveat that results are indicative and that signed DTU/CCTP documents take precedence — a reliability signal an agent cannot get from annotations. It does not describe the shape of the verification output, which keeps it from 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?

Front-loaded with the trigger phrase, then structured check list, then caveat — easy to scan. The scene line partially repeats the four checks already listed in the first sentence, which is minor redundancy but not harmful.

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 single-parameter, read-only, closed-world check tool with full schema coverage and annotations covering safety, this is nearly complete. The only residual gap is that no output schema exists and the description never hints at what the verification returns (report, non-conformity list, etc.), which an agent might want to know.

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's `scene` description is essentially identical to the description's "scene : adoucisseur {alimentation, evacuation, bypass, acces}", so no additional semantics are conveyed. Baseline 3 applies since the schema already documents the single nested 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?

States a specific verb (VÉRIFIER) and resource (ADOUCISSEUR D'EAU), then enumerates the four exact check points with their codes (AD-ALIMENTATION, AD-EVACUATION, AD-BY-PASS, AD-ACCES). This distinguishes it from the many other cao_bim_* element tools, which all share the same verb but target different building elements.

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?

"Appelez quand vous devez VERIFIER L'ADOUCISSEUR D'EAU" gives an explicit triggering condition, and "Indicatif — DTU plomberie et CCTP signes priment" tells the agent when its output should be overridden by authoritative documents. It does not name an alternative sibling tool or state when NOT to call it, keeping it out of the top band.

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 and destructiveHint=false, and the description's 'Lecture seule' is redundant with that. However, it adds a valuable caveat: 'Indicatif — note de calcul CVC et CCTP signes priment', which tells the agent the output is advisory and authoritative documents prevail.

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 call condition and packed into one compact paragraph. It loses some efficiency by restating the scene structure and the four sub-check categories, but it remains dense and readable.

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 single-parameter, read-only, indicative checking tool with no output schema, the description covers what it verifies and the authority caveat. It is largely complete, though explicit routing to sibling tools for non-aerotherme checks would improve it further.

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 parameter is already documented as 'Scene CAO : aerotherme {reseau, regulation, fixation, securite}'. The description repeats the same structure ('scene : aerotherme {reseau, regulation, fixation, securite}') without adding format, validation, or nesting details 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 uses a specific verb and resource: 'VERIFIER L'AEROTHERME', and enumerates the checked aspects (network, regulation, fixing, safety). It clearly identifies the tool's scope but does not explicitly differentiate it from nearby siblings such as cao_bim_cvc or cao_bim_regulation_chauffage.

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 call it ('Appelez quand vous devez VERIFIER L'AEROTHERME') and lists the covered sub-checks. It gives no when-not conditions or named alternatives, but the invocation context 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?

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful context by stating 'Lecture seule' and, more importantly, that the result is indicative and that manufacturer technical notices take precedence. This is useful behavioral disclosure beyond structured fields, though return format is not described.

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 call condition and purpose before moving into structural details. Every clause carries domain-specific information, with no filler sentences. It is slightly repetitive in restating the 'scene' structure already in the schema, but overall efficient.

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 nested object parameter and no output schema, the description gives enough context to call it correctly: the required scene shape, the classification thresholds, and the indicative nature of the result. It does not describe what the return value looks like (e.g., conformity verdict per element), which is a minor gap but not blocking for 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 coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema's generic summary. It spells out the nested structure of 'scene.menuiseries_aev' with fields (element, exposition, classement, pose) and gives example exposure/classement values and threshold logic (A2E3V2 for faible, A3E5V2 for moderee, A4E6V3 for forte), which an agent could not infer from the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific trigger and verb: 'Appelez quand vous devez verifier le CLASSEMENT AEV des menuiseries (NF DTU 36.5)'. It names the exact resource (menuiseries), the regulatory framework (NF DTU 36.5), and the classification dimensions (air/eau/vent), which clearly distinguishes it from siblings like cao_bim_vitrages or cao_bim_etancheite.

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 phrase 'Appelez quand vous devez verifier...' gives explicit when-to-use guidance. It also includes a caveat that the result is 'Indicatif — avis techniques fabricants priment', which helps the agent understand the tool's role. It does not name an alternative sibling tool for related checks, so it falls 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so 'Lecture seule' merely echoes them. The added value is the caveat 'Indicatif — normes NF EN 1176/1177 et PV de contrôle signés priment', which tells the agent the result is advisory and superseded by signed inspection reports - a behavioural trait not in any structured 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?

One dense paragraph with the trigger and scope front-loaded before the schema recap and the 'Indicatif' caveat. No filler sentences, though the inline AJE-code abbreviations make it slightly harder to scan than plain prose.

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?

Covers trigger, the four inspected sub-areas, the nested scene input, and the authority caveat. With no output schema the description does not explain return shape, but for a zero-required-param indicative checker the 'indicatif / PV priment' qualifier supplies the most decision-relevant missing context.

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 single 'scene' object is already documented with its {sol, equipements, cloture, entretien} shape. The description restates that structure and adds only the AJE code labels, so per the high-coverage baseline a 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 in caps - VERIFIER LES AIRES DE JEUX - and enumerates the four checked sub-areas (sol amortissant, équipements, clôture, entretien) with their AJE codes. An agent can distinguish this playground-specific checker from generic siblings like cao_bim_cloture or cao_bim_sols_souples 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 ('Appelez quand vous devez...') and names the domain ('gestion locative'). It does not name exclusions or point to alternative siblings (e.g. use cao_bim_cloture for fencing alone), so it stops short of full when-not 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?

Annotations already declare readOnlyHint/destructiveHint, so "Lecture seule" adds nothing. What does add value is "Indicatif — DTU et CCTP signes priment": it warns the agent that the result is non-normative and that signed DTU/CCTP documents override it, which is essential framing for a compliance-check tool. It does not describe output form, but the caveat is the behaviourally important part.

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 trigger clause followed by the check list and two short caveats; every element is useful. Minor waste from restating the scene structure twice (prose and brace notation), but the whole thing is a few lines.

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 read-only check with a nested object parameter and no output schema, the description covers what is checked and the precedence caveat well, but leaves the nested scene payload undefined — an agent cannot tell what to put inside it. Adequate but with a clear gap given nested-object complexity.

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 there is only one parameter, but the schema entry is a verbatim copy of the description's "scene : allege {isolation, etancheite, fixation, finition}". Neither source explains the shape of the nested scene object (what geometry, attributes or units it must contain), so the description adds no semantics beyond the schema. 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?

States a specific verb and object: "VERIFIER L'ALLEGE de baie", then enumerates the four axes checked (AL-ISOLATION, AL-ETANCHEITE, AL-FIXATION, AL-FINITION). Against the enormous cao_bim_* sibling list, the subject (window spandrel) is unambiguous. It stops short of naming any neighbouring tool it should be preferred over, so a 4 rather than 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?

"Appelez quand vous devez VERIFIER L'ALLEGE de baie" is an explicit invocation trigger, and the four sub-checks tell the agent what will be covered. No exclusions or alternative tools are mentioned, and nothing tells the agent when NOT to call it, so it falls short of the 5 bar.

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, destructiveHint=false, openWorldHint=false, and the description corroborates with 'Sans modifier la scene' rather than contradicting. It adds real behavioral value beyond the annotations: the exact pipeline, the lossless guarantee, and that additions (inferred roof/floor) and fidelity gaps (dimensions, materials) are reported rather than treated as errors.

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?

A single dense paragraph that front-loads the trigger phrase and flows into mechanism, guarantees, and return shape. Every clause carries information, though the return-field list makes the sentence long.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by enumerating the returned keys ({ok, elements_avant, elements_apres, pertes, ajouts, avertissements, ifc_octets}) and covering input, procedure, guarantees, and non-mutation. An agent has everything needed to select and invoke 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 100%, so both parameters are already documented in the schema. The description only implicitly hints at 'inclure_ifc' through the returned ifc_octets field and adds no format or default detail beyond the schema, which is the expected baseline when the schema does the work.

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 verb and resource: verifying a full IFC round-trip of a CAD scene, with the mechanism spelled out (export IFC4 via ifcopenshell, reimport, semantic compare). This clearly separates it from export-only siblings like cao_generer_ifc, import siblings like cao_importer_ifc, and conflict/integrity siblings like cao_conflits_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?

Opens with an explicit trigger condition ('Appelez quand vous devez verifier l'aller-retour IFC complet d'une scene CAO'). It gives a clear when-to-use but never names an alternative tool or states when NOT to use it, so it stops short of full routing 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?

Annotations already declare readOnlyHint/destructiveHint=false, so "Lecture seule" adds nothing new. The description does earn credit with a genuine caveat: results are indicative and a signed fixing calculation note prevails, which tells the agent how far to trust the output. It stops short of describing what the response contains.

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 call condition and packed into a few dense lines with no filler. The shorthand criteria codes (AN-TYPE, AN-CAPACITE…) make it terse, though slightly cryptic for an agent that does not know those codes.

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 read-only single-parameter check tool with no output schema, the description covers what is verified, the trust level of the result, and the parameter shape. Only the return value's structure is left unexplained, which is a minor gap here.

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?

Only one parameter, and schema coverage is 100%, so the schema already documents the scene object and its ancrages fields. The description restates the same field list {type, capacite_kn, nombre, corrosion} without adding format or validation nuance beyond it, matching the 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?

States a specific verb (VERIFIER LES ANCRAGES) and enumerates the exact criteria checked: declared type, verified capacity in kN, count per support >= 2, corrosion protection. It is unmistakably distinct from siblings like cao_bim_pieux or cao_bim_assemblages_acier in subject matter, though it never names an alternative tool 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?

"Appelez quand vous devez VERIFIER LES ANCRAGES" gives a clear invocation condition, and "Indicatif — note de calcul de fixation signee prime" tells the agent not to treat the result as authoritative. No sibling alternative is named for a narrower/broader check, which keeps it out of 5 territory.

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, destructiveHint=false and openWorldHint=false, and 'Lecture seule' only echoes that. The genuinely added value is the caveat that the result is indicative and that signed CCTP / règlement de copropriété prevail — a reliability constraint not present in any structured 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 trigger condition is front-loaded in caps, followed by the sub-criteria and the normative caveat in one compact block. Dense with codes but every clause carries information; no filler sentences.

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?

Purpose, scope and the advisory nature are covered, but there is no output schema and the description never indicates what a check returns (findings, non-conformities, a verdict). For a verification tool the agent still has to guess the shape of the result.

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% and the nested scene object is already documented, so the baseline would be 3. The description goes slightly beyond by mapping each sub-key to a check code (AP-EMPLACEMENT, AP-DISPOSITIF, AP-ENTRETIEN, AP-SECURITE), clarifying what each branch of the scene should contain.

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: verify anti-pigeon devices (emplacement, dispositif, entretien, sécurité) on a scene, with the four AP-* check codes enumerated. The domain is narrow enough that it is clearly distinguishable from the surrounding cao_bim_* siblings, though no sibling is named 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?

'Appelez quand vous devez VERIFIER LES DISPOSITIFS ANTI-PIGEONS' gives an explicit invocation trigger. There is no statement of when-not to use it or of an alternative tool, so it stops short of full routing 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?

Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so the 'Lecture seule' repetition adds little. However, 'Indicatif — reglement sanitaire et CCTP signes priment' is genuinely valuable beyond structured fields: it warns the agent that results are not authoritative and must defer to referenced regulations and signed CCTPs.

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?

Compact and front-loaded: call condition first, then the code list and scene structure, then the caveat. The telegraphic style is efficient, though the nested-structure line is somewhat redundant with the schema.

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 single-optional-parameter, read-only check tool with rich annotations and no output schema, the description covers when to call, what is verified, and the authority caveat. It does not describe the result payload, but the enumerated criteria imply it adequately.

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% and there is only one optional nested parameter; the description restates the nested anti_refoulement structure already present in the schema. It adds no extra semantics about expected scene content or shape beyond the schema 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?

States a specific verb (VERIFIER) and resource (anti-refoulement / clapet anti-retour), and enumerates the exact sub-criteria checked (type, entretien, accessibilite, signalisation) with their codes. Against a very large sibling list of cao_bim_* tools, this is unambiguously identifiable.

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 'Appelez quand vous devez VERIFIER...' gives a clear triggering condition. It does not name alternative tools or exclusions, but the domain is narrow enough that the use case is unambiguous.

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/destructiveHint, so 'Lecture seule' is redundant, but the description adds genuine context beyond them: results are 'Indicatif' and subordinate to DTU standards and signed layout documents. It does not say what the tool returns when the scene lacks sills/thresholds or what a failing check looks like.

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?

Densely front-loaded: trigger first, then check codes, then parameter shape, then the normative caveat. Every element is relevant, though 'scene : appuis_seuils {...}' and 'Lecture seule' duplicate structured fields and could be trimmed.

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 annotations carrying the safety profile and the checks enumerated, an agent knows what the tool inspects and how much to trust it. The main remaining gap is return-value behavior, since no output schema exists and the description never says what findings or codes come back.

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 description merely repeats the same field list ({rejingot, pente, etancheite, rpt}) already present in the schema. Since 'scene' is optional (0 required params on a nested object), the description could have explained the default behavior when omitted, but does not.

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 ('VERIFIER') and a narrowly scoped resource ('APPUIS ET SEUILS / appuis de baie / seuils'), then enumerates the four checks with their codes (AP-REJINGOT, AP-PENTE, AP-ETANCHEITE, AP-RPT). That is enough for an agent to recognize the domain, though it never contrasts itself with plausible siblings like cao_bim_etancheite or cao_bim_ponts_thermiques, which cover overlapping concerns.

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 'Appelez quand vous devez VERIFIER...' gives an explicit triggering condition, and the caveat that DTU 20.12/36.5 and signed calepinage prevail frames when this tool's answer is authoritative. No alternative tool or exclusion is named, so it stops short of full routing 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?

Beyond the annotations, the description discloses the critical behavioural trait that results are indicative only and that signed Eurocode 2 / CCTP documents prevail, which shapes how an agent should present findings. "Lecture seule" merely restates readOnlyHint=true and adds nothing, but the non-authoritative-result caveat is genuinely useful context.

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 trigger and the four check categories are front-loaded and compressed into one dense sentence, with the caveat and read-only note trailing. Slight redundancy between the enumerated checks and the scene field list costs it the top score.

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 single-object, read-only check tool with no output schema, the description covers what is inspected and that the verdict is indicative, but never says what a check returns (verdict, list of non-conformities, tolerances). That is a real gap given the absence of an output schema.

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% and the schema already documents the single scene object with its four fields, which the description repeats almost verbatim. The only marginal addition is the mapping of each field to a check code, 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?

States a specific verb (VERIFIER) and resource (ARMATURES D'ATTENTE) and enumerates the four checked aspects with explicit check codes (AA-POSITION, AA-ANCRAGE, AA-DIAMETRE, AA-PROTECTION), so the scope is unambiguous. It does not, however, distinguish itself from near-neighbour siblings such as cao_bim_ancrages, cao_bim_chainages or cao_bim_bordereau_armatures.

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?

"Appelez quand vous devez VERIFIER LES ARMATURES D'ATTENTE" gives an explicit invocation trigger, which is more than most siblings offer. There is no exclusion clause or pointer to a competing tool, so the agent gets context but no routing 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?

Annotations already declare readOnlyHint/destructiveHint=false, and the description adds a substantive caveat beyond them: the result is "indicatif" and a signed CCTP espaces verts takes precedence. That tells the agent not to treat the check as authoritative, which is real behavioral context; return format is still unspecified, though no output schema exists to demand it.

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 trigger phrase, then the component list, then the caveat, all in two compact sentences. The component enumeration and the shape notation partly restate each other, which costs a little tightness but keeps the definition scannable.

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 read-only, single-optional-parameter check whose safety profile is already in annotations, the description covers scope, components, and the authoritative-source caveat. The absence of any hint about what the check returns is the main remaining gap, mitigated by there being no output schema to explain.

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% and the schema already describes the arrosage object shape, so the baseline would be 3. The description adds value by mapping each sub-element to a reference code (AR-RESEAU, AR-PROGRAMMATEUR, AR-RECUPERATION, AR-ANTIGEL), giving semantic content the schema alone does not.

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 (VERIFIER) and resource (RESEAU D'ARROSAGE, espaces verts), then enumerates the four sub-scopes with their reference codes (AR-RESEAU, AR-PROGRAMMATEUR, AR-RECUPERATION, AR-ANTIGEL). Against hundreds of cao_bim_* siblings, an agent can immediately tell this is the irrigation-network check rather than a generic BIM 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?

"Appelez quand vous devez VERIFIER LE RESEAU D'ARROSAGE" is an explicit trigger condition scoped to green spaces. No when-not conditions or named alternatives are given, but the domain scoping effectively routes the agent away from unrelated cao_bim_* checks.

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=true, openWorld=false, destructive=false. The description adds a genuinely new caveat, 'Indicatif — controle technique obligatoire', telling the agent the result is not a substitute for mandatory inspection. The repeated 'Lecture seule' is redundant and no return format is described.

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 trigger and then a compact checklist; almost every clause carries a concrete threshold or safety item. It is dense and run-on, which slightly hurts readability but no clause 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?

Single optional parameter, high schema coverage, no output schema. The description gives enough to know what the check evaluates and its indicative nature; the only gap is the shape of the returned result, which is implicit for a 'vérifier' 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 100% so the schema carries baseline semantics, but the description goes further by spelling out the fields of each ascenseur object (gaine, fosse_m, machinerie, cabine) and the thresholds they're compared against, which adds real meaning.

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 concrete verb (vérifier) and resource (ASCENSEUR) and anchors it to EN 81 and the 20/04/2017 arrêté, then enumerates the exact dimensions and safety elements checked. This lets an agent tell it apart from generic siblings like cao_bim_accessibilite or cao_bim_conformite 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?

Explicit trigger stated: 'Appelez quand vous devez verifier un ASCENSEUR'. Coverage of the recourse is strong, but no when-not conditions or named alternative sibling are given to route away from it.

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 and destructiveHint=false, so 'Lecture seule' is largely redundant. What the description does add beyond annotations is the epistemic caveat that results are indicative and are superseded by signed soil studies and SPANC controls — meaningful context about how much weight to give the output.

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, front-loaded sentence carries the call trigger, all four checks and their thresholds, followed by a short caveat. No filler, though the capitalised rule codes make it slightly hard to scan.

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 read-only, single-parameter verification tool with no output schema, the description covers what is checked, the thresholds used, and the authority caveat. It does not say what the check returns (e.g. pass/fail per criterion), which is the one remaining 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 description coverage is 100% and the single 'scene' parameter is already documented as {filiere, eh, distance_habitation_m, distance_limite_m, etude_sol}. The description restates the same field list without adding types, units or accepted enum values, 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?

The description states a specific verb ('VERIFIER L'ASSAINISSEMENT NON COLLECTIF') plus the exact resources checked: filiere declared, capacity >= 4 EH, regulatory setbacks (5 m / 3 m) and soil study, each tagged with a rule code (ANC-FILIERE, ANC-EH, ANC-DISTANCES, ANC-SOL). This clearly separates it from generic siblings such as cao_bim_eaux_usees or cao_bim_evacuation.

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 call condition ('Appelez quand vous devez VERIFIER...'), so the when-to-use case is unambiguous. It also adds a caveat on reliability ('etude de sol et controle SPANC signes priment') but never names an alternative sibling tool, so there are no explicit exclusions or routing alternatives.

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, destructiveHint=false and openWorldHint=false, and the description reinforces that with "Lecture seule." More valuable is the explicit credibility caveat — "Indicatif — Eurocode 3 et CCTP signes priment" — which tells the agent the result is advisory and that normative documents override it, a behavioural fact not present in the structured fields. Return format and what a 'non-conformité' looks like are not described.

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?

A single front-loaded trigger clause followed by the enumerated sub-checks, the scene shape, and the caveat — no filler sentences. It is dense but every clause carries information; the repetition of the scene structure already in the schema is the only near-redundancy.

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 nested object input, annotations covering safety, and a reliability caveat stated, the definition gives an agent enough to invoke correctly. Since no output schema exists, a brief note on what the check returns (findings per sub-assembly vs. a pass/fail verdict) and whether scene is required would close the remaining 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 description coverage is 100% and there is only one parameter, so the schema already carries the full burden. The description repeats the same per-parameter breakdown ("scene : assemblage_poteau_poutre {platine_about, boulons, jarret, protection}") without adding attributes, expected units, or what happens when a sub-key is absent. Baseline 3 applies when high coverage lets the schema do the work.

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 — checking a steel beam-to-column connection — and enumerates the four sub-elements verified (platine d'about, boulons, jarret/gousset, protection), each tied to a code (AP-PLATINE-ABOUT, AP-BOULONS, AP-JARRET, AP-PROTECTION). What it does not do is differentiate itself from closely named siblings such as cao_bim_assemblages_acier, cao_bim_platines or cao_bim_boulons_hr, so an agent must infer the boundary.

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?

"Appelez quand vous devez VERIFIER L'ASSEMBLAGE POTEAU-POUTRE acier" names a trigger, but it largely restates the tool's own purpose rather than contrasting with alternatives. With dozens of adjacent cao_bim_* assembly, bolt, haunch and plate tools available, no exclusion or alternative routing is offered, leaving the agent to guess when this check applies instead of a neighbouring one.

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/destructive/openWorld, and the description reinforces with "Lecture seule" while adding the non-obvious caveat that results are "Indicatif" and subordinate to a signed calculation note — real behavioral context an agent would otherwise miss. It does not say what the response looks like or how results are graded, which keeps it below 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?

Single front-loaded imperative clause followed by the four sub-checks and the indicative/read-only caveat; every segment carries information. The compressed code-and-brace notation is dense 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?

For a single-parameter, read-only, no-output-schema check tool, the description covers scope, the four check families, and the authority caveat. What remains unstated is the shape of the returned diagnostic (per-family status? findings list?), which an agent writing the follow-up call would benefit from.

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 is one optional parameter (scene) with 100% schema description coverage, so the schema already documents it. The description's "scene : assemblages_acier {boulons, serrage, soudures, platine}" merely restates the schema text and adds no syntax, required-vs-optional, or structure guidance beyond it.

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 (VERIFIER) and resource (assemblage acier / connexions métalliques) and enumerates the four checked families with reference codes (AS-BOULONS, AS-SERRAGE, AS-SOUDURES, AS-PLATINE), which genuinely separates it from broad steel siblings like cao_bim_ossature_acier or cao_bim_structure. It never names a sibling explicitly, so differentiation is inferred from scope rather than stated.

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?

"Appelez quand vous devez VERIFIER L'ASSEMBLAGE ACIER" gives an explicit trigger condition, and the caveat "note de calcul d'assemblage signée prime" signals the boundary where this tool's output should be superseded by a signed design note. No alternative tool is named for the adjacent case (e.g. if you only need the steel frame model itself), so routing is implied rather than resolved.

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/openWorldHint=false/destructiveHint=false, and the description adds real substance: the DO policy must be dated before site opening (L. 242-1), decennale/RC pro are assessed per company per lot, and "les attestations reelles priment" tells the agent that declared scene data can be overridden by actual certificates. It does not describe the shape of the verdict returned, which is the one remaining gap.

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 activation condition is front-loaded, then the evidence required and the scene shape. Slight redundancy in restating the scene fields almost verbatim from the schema, and the legal citations add density, but no sentence is 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 read-only, single-parameter tool with annotations and no output schema, the description supplies the domain rules, the required evidence, and the precedence of real attestations. What is still unstated is what the result looks like (per-item compliance findings versus a boolean), which keeps it just under 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 coverage is 100% and the description largely mirrors the scene structure, but it adds meaning the schema does not: the DO date is constrained relative to the site start date, and decennale/rc_pro are evaluated per entreprise per lot. That goes beyond field naming into how values are judged.

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?

Specific verb + resource: verify the mandatory construction insurances, and it enumerates the exact checks (dommages-ouvrage, decennale, RC pro per lot, permis affiche, panneau, declaration d'ouverture). No sibling tool covers insurance verification (the nearest, cao_bim_securite_chantier or cao_bim_conformite, are clearly different domains), so an agent can route without 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?

"Appelez quand vous devez verifier les ASSURANCES OBLIGATOIRES de la construction" gives an explicit activation trigger plus the legal basis for each check. It stops short of naming an alternative or a when-not condition, so it lands at 4 rather than 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so 'Lecture seule' mostly repeats structured data. The valuable addition is the disclosure that the check is indicative and that signed CCTP and labour code override it — genuinely relevant behavioural context about how much to trust the output. It says nothing about the shape or granularity of the verdict, which is why it stops short of 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?

One densely packed sentence front-loads the call trigger, then the four domain codes, then the scene shape, then the caveat. No filler, no redundancy; the acronyms substitute for longer prose efficiently.

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?

Read-only, single optional parameter, no output schema — yet the description never indicates what comes back (a per-domain verdict, a list of findings, a compliance flag). For a tool that emits a check result with no output schema to lean on, that omission leaves the agent unable to anticipate the response.

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 nested 'scene' parameter, and the schema description already lists atelier {ventilation, electricite, eclairage, securite}. The description restates that same structure without adding expected formats, units, or which sub-keys are required, so it adds no 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 names a specific verb ('VÉRIFIER') and resource ('l'atelier / local technique bricolage') and enumerates the four checked domains with their identifiers (ATL-VENTILATION, ATL-ELECTRICITE, ATL-ECLAIRAGE, ATL-SECURITE). That makes the scope unambiguous against the many narrow cao_bim_* siblings such as cao_bim_eclairage or cao_bim_ventilation_naturelle, though none of those siblings are named 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?

'Appelez quand vous devez VÉRIFIER L'ATELIER' gives an explicit trigger condition, and the closing caveat tells the agent the result is indicative, with CCTP and the code du travail taking precedence. No exclusion or alternative tool is named, so the agent must infer when to prefer a narrower sibling like cao_bim_securite_chantier.

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 readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine context beyond that: the result is 'Indicatif' and signed ERP regulations and the CCTP take precedence, which tells the agent how much weight to give the output. It remains silent on return shape and any rate/scope 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?

It is short and front-loads the call trigger before the field enumeration. The final clause restating 'scene : atrium {structure, vitrage, desenfumage, securite}' duplicates the schema description word for word, a minor redundancy.

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 carries the burden of explaining what a 'check' returns, and it never says. It is adequate for selecting the tool but leaves the agent guessing about the result structure of this indicative multi-domain audit.

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 is a single nested parameter with 100% schema description coverage, so the baseline is 3. The description's 'scene : atrium {structure, vitrage, desenfumage, securite}' merely repeats the schema text verbatim rather than clarifying the shape or expectations for the nested object.

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 ('VERIFIER') and resource ('ATRIUM / hall vitre central') and enumerates the four checked domains (structure, vitrage, desenfumage, securite) with their ATR- codes, which sets it apart from narrower siblings like cao_bim_desenfumage or cao_bim_vitrages. It does not name an alternative tool, so it falls short of the sibling-differentiation bar for 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?

'Appelez quand vous devez VERIFIER L'ATRIUM' gives an explicit trigger condition. However, with hundreds of sibling tools in this namespace, there is no statement of when NOT to use it or which narrower sibling to prefer for a single-aspect check.

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/destructiveHint=false, and 'Lecture seule' simply echoes that. The real added value is 'Indicatif — reglement ERP et CCTP signes priment', which tells the agent the returned verdicts are advisory and may be overridden by ERP regulation or signed CCTP documents — a material behavioral caveat an agent must know before acting on results. Return format is not described, but no output schema exists and this is a read-only check.

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?

Telegraphic and front-loaded: the activation condition comes first, then the domain list, then the object shape, then the disclaimer. No filler sentences. The object shape is stated twice (once via AD-* codes, once via sub-keys), a minor redundancy that does serve to map regulation articles to keys.

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 one-parameter, read-only check with annotations covering the safety profile, the description supplies what matters: what is checked, that results are indicative versus ERP/CCTP. Remaining gaps are the behavior with an empty/absent 'scene' argument and what the response contains, but neither is critical 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 coverage is 100% and the single 'scene' parameter is already described as the auditorium object with its four sub-keys; the description restates that structure without adding syntax, expected value types, or a convention for the AD-* codes. Baseline 3 applies since the schema does the documentation work. It also never says what happens if 'scene' is omitted (0 required parameters).

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?

Specific verb ('VERIFIER') plus resource ('AUDITORIUM / salle de spectacle') and an explicit enumeration of the four domains covered (acoustique, eclairage, ventilation, securite) with their regulation codes. It clearly reads as an aggregate multi-domain check rather than a single-topic one. It stops short of naming which sibling does single-topic checks (e.g. cao_bim_acoustique, cao_bim_eclairage), leaving the boundary implicit.

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?

'Appelez quand vous devez VERIFIER L'AUDITORIUM' gives a positive call condition, which is better than nothing. However, there is no when-not guidance and no reference to the many narrower siblings (cao_bim_acoustique, cao_bim_ventilation_*, cao_bim_incendie) that an agent should prefer for a single aspect, so the choice among them is left to inference. The 'Indicatif' caveat hints that authoritative checks happen elsewhere, but doesn't say where.

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, destructiveHint=false and openWorldHint=false, so 'Lecture seule' is mostly redundant. However, the caveat 'Indicatif — note de calcul et CCTP signes priment' adds genuinely new behavioral context: the result is a non-authoritative screening check subordinate to signed engineering documents. No detail on output shape or severity levels.

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 front-loaded sentence that leads with the invocation trigger and then enumerates the checks, with zero filler. Minor redundancy: the scene shape repeats the four check names already listed, so that clause earns little.

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 one-parameter, read-only, indicative check with no output schema, the description covers what is inspected and how authoritative the result is. It is only slightly thin on what the agent gets back (per-check verdicts vs. a single status), which matters for a tool named 'check'.

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 is a single parameter with 100% schema description coverage, and the description's 'scene : auvents {fixation, etancheite, charges, securite}' merely restates the schema's own description string. It adds no structural or format detail (e.g. whether those keys are booleans, objects, or optional), 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 verb (VERIFIER) and resource (AUVENTS / MARQUISES) and enumerates the four sub-checks with stable identifiers (AU-FIXATION, AU-ETANCHEITE, AU-CHARGES, AU-SECURITE), which pins the scope to awnings/canopies. It never names sibling tools (cao_bim_pergolas, cao_bim_carports, cao_bim_etancheite), so differentiation is inferred from the object class rather than stated.

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: 'Appelez quand vous devez VERIFIER LES AUVENTS / MARQUISES', giving a clear condition for invocation. There is no when-not guidance and no named alternative for overlapping concerns (e.g. waterproofing or snow-load checks handled by other 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?

Annotations already establish read-only, non-destructive, closed-world behavior, so the description repeats 'Lecture seule'. What it adds beyond the annotations is the reliability caveat: 'Indicatif — documentation fabricant signee prime', which tells the agent the output is heuristic and must not override signed manufacturer documentation. That is real decision-relevant context, though return shape and verdict semantics are unspecified.

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, front-loaded block that leads with the trigger and ends with the caveat. It wastes a clause restating the schema ('scene : avis_technique {produit, avis, marquage, fabricant}'), but overall it is tight.

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 single-parameter, read-only, no-output-schema verifier, the description covers what is checked, that results are indicative, and who prevails in case of conflict. The main residual gap is what a result actually contains (pass/fail, missing documents, non-conformities).

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% and the single param already carries the same '{produit, avis, marquage, fabricant}' hint, so the schema does the heavy lifting. The description adds the AT-* code labels mapped to each key, which is a modest semantic gain, but it does not explain the nested object's value types or which keys are actually required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb in caps ('VERIFIER') and a precise resource ('AVIS TECHNIQUE / CERTIFICATION d'un produit ou fabricant'), then enumerates the four sub-checks with codes (AT-PRODUIT, AT-AVIS, AT-MARQUAGE, AT-FABRICANT). An agent immediately knows this is a certification/approval checker. It does not, however, distinguish itself from close siblings such as cao_bim_certification, cao_bim_fiche_fabricant or cao_bim_referencement_fabricants.

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?

'Appelez quand vous devez VERIFIER...' gives an explicit trigger condition with clear context. No exclusions or alternative tools are named, so the agent gets a when-to-use but not a when-not-to-use.

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, openWorldHint=false and destructiveHint=false, and "Lecture seule" merely repeats that. The one genuine addition is the caveat that results are indicative and that signed DTU/CCTP documents prevail, which tells the agent how much authority to give the output; no return shape or finding format is described.

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 call condition and the checked items, then the caveat last — a sensible order with little waste. The scene structure is repeated a second time from the schema, a minor redundancy.

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 read-only single-parameter checker this covers what is checked and the authority caveat, but with no output schema the description never hints at what comes back (list of non-conformities, verdict, codes). An agent knows when to call it but not what to expect.

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?

A single optional parameter with 100% schema coverage, so the schema already documents the scene object. The description restates the same {emplacement, dimensionnement, entretien, ventilation} structure without adding format, requiredness, or expected node semantics.

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 gives a specific verb (VERIFIER) and resource (BAC A GRAISSE) and enumerates the four checked sub-topics with their codes (BG-EMPLACEMENT, BG-DIMENSIONNEMENT, BG-ENTRETIEN, BG-VENTILATION). That makes the scope unmistakable against neighbors like cao_bim_eaux_usees or cao_bim_raccordement_egout, though no sibling is named explicitly to draw the boundary.

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?

"Appelez quand vous devez VERIFIER LE BAC A GRAISSE" states an explicit trigger condition for invocation. It does not say when to prefer an adjacent tool (e.g., the generic sanitary/drainage checkers) or any prerequisites, so it stops short of full routing 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so 'Lecture seule' merely restates structured data. The genuinely additive item is 'Indicatif — reglementation assainissement et CCTP signes priment', which warns that results are non-normative and that signed documents prevail; that is useful but there is nothing on error behavior or what the tool inspects in the scene.

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 invocation trigger, then the four audit domains, then the scope object and the caveat. No sentence is padding, and the dense label-based style suits a domain vocabulary 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 nested-object, read-only check with no output schema, the description explains the audit domains and the indicative caveat, which covers most of the need. It never indicates what the check returns (findings, conformity verdicts, per-domain status), leaving the agent to guess the response shape.

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?

Only one parameter, and schema description coverage is 100% with the same 'bac_decantation {emplacement, dimensionnement, entretien, acces}' text appearing in both schema and description. The description adds no format, depth or expected-structure detail beyond the schema, 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?

States a specific verb (VÉRIFIER) and resource (BAC DE DECANTATION) and enumerates the four checked domains (emplacement, dimensionnement, entretien, accès) with their codes, so the agent knows exactly what is audited. It does not, however, distinguish itself from many close siblings such as cao_bim_bac_a_graisse, cao_bim_assainissement or cao_bim_eaux_usees.

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?

'Appelez quand vous devez VERIFIER LE BAC DE DECANTATION' gives an explicit trigger condition for invocation, which is more than most siblings offer. It stops short of stating when not to use it or naming the alternative tool to pick when the scope is a different sanitation component.

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 cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint=false), and 'Lecture seule' merely restates them. The added value is 'Indicatif — DTU plomberie et CCTP signes priment', which tells the agent the result is non-normative and can be overridden by contractual documents — a real caveat not present in structured fields.

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?

A single dense paragraph with the trigger verb first, then the check list, then the caveat — well front-loaded and waste-free. The parenthetical codes (BG-ROBINETTERIE, etc.) add bulk that is somewhat opaque but plausibly useful identifiers for the agent.

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 scene-based check tool with a nested object parameter and no output schema, the description says nothing about what a check returns (findings list? per-domain verdicts? conformance flags?). The 'indicatif' caveat is a good addition, but the agent still cannot anticipate the response shape.

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?

With a single parameter at 100% schema description coverage and zero required fields, the schema already carries the meaning. The description mirrors the scene structure ('scene : baignoire {robinetterie, evacuation, fixation, etancheite}') without adding format, completeness, or nesting-depth guidance beyond what the schema states.

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 (VERIFIER) plus the exact resource (baignoire) and enumerates the four checked sub-domains (robinetterie, evacuation, fixation, etancheite) with codes. An agent can distinguish this from cao_bim_douche, cao_bim_salle_bain, or the generic cao_bim_robinetterie/cao_bim_evacuation tools 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?

The trigger is explicit and front-loaded: 'Appelez quand vous devez VERIFIER LA BAIGNOIRE'. It gives a clear context for invocation but names no exclusions or alternative tools, even though the bathtub sub-domains overlap with standalone sibling tools — that routing decision is left to the 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?

Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so the safety profile is covered; 'Lecture seule' merely repeats it. The description does add a genuinely useful behavioral caveat — 'Indicatif — DTU 20.12 signe prime' — telling the agent the verdict is advisory and may be overridden by the signed standard, which is context annotations cannot provide.

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 trigger, followed by the four check criteria and codes, then the input shape, then the caveat. Dense and mostly waste-free, with minor redundancy in restating the schema's balcons field list verbatim.

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 read-only diagnostic with one nested parameter and no output schema, the description supplies the trigger, the exact rules and thresholds applied, and the reliability caveat. The only gap is that it never indicates what the response contains (presumably per-rule EB-* verdicts), which the agent must infer.

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% with a single nested object, so the baseline is 3. The description earns an extra point by attaching evaluation thresholds to specific fields (pente_pct >= 1 %, releve_etancheite_mm >= 150 mm), meaning the agent learns how each field will be judged, not just that it exists.

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 (VERIFIER) and a tightly scoped resource (balcony waterproofing: slope, upstand, drainage, guardrail) with the governing standard DTU 20.12. This is clearly distinguishable from the broader siblings cao_bim_etancheite and cao_bim_garde_corps by its balcony-specific scope, though no sibling is named 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?

'Appelez quand vous devez VERIFIER L'ETANCHEITE DES BALCONS' gives an explicit activation trigger. It stops short of stating when NOT to use it or pointing to the general-purpose waterproofing/guardrail tools for non-balcony 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, and the description's 'Lecture seule' is a restatement. The real added value is the caveat that the check is indicative and that signed DTU plomberie and CCTP prevail, which tells the agent how much weight to put on the result.

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 trigger followed by a compact checklist, with the disclaimer last where it belongs. Dense but every clause maps to a check the tool performs; the BE-* codes in parentheses are the only mildly noisy element.

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 read-only, single-nested-parameter verification tool with no output schema, the description covers what is inspected, on what input shape, and the normative caveat. Return value structure is unspecified but that is tolerable given no output schema is declared.

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 single parameter already documents the nested ballon_ecs object; the description repeats the same sub-field list (alimentation, groupe_securite, fixation, acces) without adding format, expected values, or required-vs-optional detail. 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 verb in caps (VERIFIER) plus the exact resource (ballon ECS / chauffe-eau) and enumerates the four control points with their BE-* codes. This distinguishes it clearly from adjacent siblings in the dense catalogue such as cao_bim_ballon_tampon, cao_bim_production_ecs and cao_bim_bouclage_ecs.

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?

'Appelez quand vous devez VERIFIER...' gives an explicit trigger condition for invocation. It does not name alternatives or state when not to use it (e.g. when the target is a buffer tank rather than an ECS cylinder), so it stops short of full routing 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so "Lecture seule" is redundant. The genuinely additive information is that the result is indicative and that signed DTU/CCTP documents take precedence, which is real behavioral context, but return format and failure behavior are unaddressed.

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 imperative with the checkpoint codes inline and the caveat closing the paragraph; nearly every clause is informative. The French phrasing is dense 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?

A single-object, read-only, fully-documented parameter with no output schema and safety fully covered by annotations leaves little for the description to do. The indicative/signed-document caveat fills the main remaining ambiguity, though it could mention what the check returns.

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% and the single 'scene' parameter is described in the schema identically to the description (ballon_tampon {raccordement, isolation, vidange, acces}). The description adds no syntax or structure detail beyond what the schema already provides, 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 verb (VERIFIER / verifier) and a specific resource (ballon tampon) with the four audit checkpoints (BT-RACCORDEMENT, BT-ISOLATION, BT-VIDANGE, BT-ACCES) enumerated. The resource is distinct enough from close siblings like cao_bim_ballon_ecs, though the description never explicitly contrasts with them.

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?

"Appelez quand vous devez VERIFIER LE BALLON TAMPON" gives a clear trigger condition, and "Indicatif — DTU et CCTP signes priment" clarifies the tool's authority level. It does not name a sibling or a when-not-to-use condition, so it stops short of the top band.

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, destructiveHint=false and openWorldHint=false; the description reinforces with 'Lecture seule' and, more valuable, adds that results are 'Indicatif' and that signed CCTP and calepinage take precedence. That precedence caveat is genuine behavioral context beyond the annotations. It does not describe the return shape or what a 'verification' produces, leaving a gap for a check-style 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 call condition is front-loaded, the enumeration maps cleanly to the four BA-* checks, and the precedence caveat closes the sentence. It is dense but every clause carries information; no filler or repetition beyond the one schema echo.

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 read-only, single-param, annotated check tool with no output schema, the description supplies purpose, scope, sub-domains, safety ('Lecture seule') and the critical indicatif/precedence caveat. What is under-specified is what the check actually returns (findings vs. a boolean vs. a report), which an agent would need when deciding how to use the result.

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 is one parameter with 100% schema description coverage, and the description's 'scene : bandeaux {fixation, etancheite, isolation, dilatation}' simply repeats the schema text verbatim. No additional syntax, expected keys, or shape details are added, so the baseline 3 for full schema coverage 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 ('VERIFIER') and resource ('BANDEAUX / CORNICHES de facade') and enumerates the four sub-checks (BA-FIXATION, BA-ETANCHEITE, BA-ISOLATION, BA-DILATATION), so an agent knows exactly what domain is covered. It does not name the sibling it replaces or contrasts with (e.g. cao_bim_acroteres, cao_bim_joints_dilatation), so it stops short of explicit sibling differentiation.

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 'Appelez quand vous devez VERIFIER...' gives a clear invocation condition, and the caveat 'Indicatif — CCTP facade et calepinage signes priment' tells the agent when this tool's output should be overridden. It gives no explicit 'do not use when' exclusions or named alternatives, so it is clear context without full routing 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's closing "Lecture seule" simply reinforces that. The genuinely additive content is "Indicatif — arrete PMR et CCTP signes priment", which warns the agent that results are non-authoritative and that normative documents override them — context no annotation provides. Return format and pagination are still unstated, keeping it below 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?

One dense, front-loaded block that opens with the trigger condition before listing check axes and then the caveat. No filler sentences, though the all-caps emphasis and code-dense phrasing make it slightly harder to parse than needed.

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 single-parameter, nested-object tool with no output schema, the description covers what is checked, the scene shape, and the authoritativeness caveat. Only the shape of the returned verdict per axis is left implicit, which the description could have stated in one clause.

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 single scene parameter and its nested sub-keys are already documented in the schema. The description restates the same four sub-keys, adding only the BP-* code naming; with the schema doing the heavy lifting, 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 verb (VERIFIER) and a precise resource (bandes podotactiles / bandes d'eveil de vigilance), then enumerates the four check axes with distinct codes (BP-EMPLACEMENT, BP-CONTRASTE, BP-CONTINUITE, BP-CONFORMITE). An agent can tell this apart from generic siblings like cao_bim_accessibilite or cao_bim_conformite 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?

"Appelez quand vous devez VERIFIER LES BANDES PODOTACTILES" gives an explicit invocation trigger, which is stronger than most sibling descriptions. It stops short of naming when-not-to-use conditions or a specific alternative tool, so it lands at 4 rather than 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?

Annotations already declare readOnlyHint/destructiveHint=false, and the description reinforces this with 'Lecture seule'. It adds genuinely useful behavioural context beyond the annotations: the check is 'Indicatif' and professional rules / manufacturer notices prevail, which tells the agent how to weight the result. It does not describe the shape of the returned verdict (list of non-conformities vs. pass/fail), which keeps it from 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?

The trigger comes first, then the rule set, then the schema hint, then the caveat — a sensible front-loaded order. It is dense but every clause carries a threshold or a constraint; only the schema restatement is partly redundant with the input schema.

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 single-parameter, read-only checking tool with no output schema, the description supplies all the domain rules and the caveat needed to invoke it and interpret it responsibly. Only the nature of the returned diagnostic (per-item compliance report?) 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% and the single nested 'scene' object is fully spelled out in the schema itself. The description restates the same field list (nom, ossature, lame_air_mm, pare_pluie, fixation, jeu_pied_mm, joint_dilatation_m) without adding units conventions, defaults, or how missing fields are handled. Baseline 3 is appropriate when the schema does the work.

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 ('verifier') and resource ('BARDAGE RAPPORTE') and enumerates exactly what is checked (lame d'air >= 20 mm, pare-pluie, ossature/fixations, jeu en pied, joints de dilatation). This differentiates it clearly from neighbours like cao_bim_etancheite, cao_bim_toiture_terrasse or cao_bim_charpente, which cover different envelope elements.

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 'Appelez quand vous devez verifier un BARDAGE RAPPORTE' gives an explicit trigger condition. It does not name a sibling alternative or state when not to use it, so it falls 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?

Annotations already declare readOnlyHint=true / destructiveHint=false, and the description simply restates that with 'Lecture seule'. It does add real context: the default output is markup XML ready for Solibri/BIMcollab and the reserves path produces a DTU snag list, but it says nothing about what the importer returns or how large/complex scenes are handled.

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 trigger ('Appelez quand...') is front-loaded and every clause carries information; no filler. The single sentence with two levels of nested parentheses is dense and slightly harder to parse than a short bulleted mode list would be.

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 three parameters with full schema coverage and annotations covering the safety profile, the definition is mostly sufficient. However, with no output schema, the return value for action=importer and action=reserves is left unspecified, and the nested scene object's expected structure is only alluded to.

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 baseline is 3, but the description goes beyond the schema by explaining what each action value produces and confirming zip_base64 is only for action=importer. The scene parameter itself gets no added semantic detail beyond the schema's format hint.

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: generate BCF 2.1 issues from IFC round-trip deviations, with the three operating modes (default scene, reserves/snag list, external ZIP import) spelled out. The scope is clear, but it never distinguishes itself from close siblings such as cao_bcf_ifc, cao_bim_aller_retour or cao_bim_reception, so an agent cannot route between them from this text alone.

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?

Explicitly opens with 'Appelez quand vous devez...' and gives a condition per mode: default when working from scene deviations, action=reserves when a reception snag list (DTU) must go to coordination, action=importer when reading an external BCF ZIP. Missing only when-not-to-use and explicit pointers to the overlapping sibling 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?

Annotations already declare readOnlyHint/openWorldHint=false/destructiveHint=false, so "Lecture seule" is redundant. The added value is "Indicatif — CCTP tertiaire signe prime": it tells the agent the output is non-normative and only becomes contractual-grade upon a signed tertiary CCTP, which is genuine trust-calibration context not present in structured fields.

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?

Three terse sentences: trigger first, then the checked sub-domains, then the scope caveat and read-only note. No filler, and the call-to-action is front-loaded.

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?

Coverage of what gets verified is good, but with no output schema the description does not say what comes back (verdict per sub-domain? list of findings? scores?) nor what happens when the scene object is empty, which matters since no parameters are required. Adequate but leaves the return contract to inference.

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?

Only one parameter (scene) with 100% schema description coverage, and the description simply restates the schema text ("scene : bibliotheque {eclairage, acoustique, mobilier, ventilation}"). Baseline 3 applies since the schema already carries the semantics and nothing new is added about the nested object's expected shape or content.

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 in caps (VERIFIER) plus the exact resource (bibliotheque / salle de lecture) and enumerates the four checked sub-domains with their codes (BI-ECLAIRAGE, BI-ACOUSTIQUE, BI-MOBILIER, BI-VENTILATION). An agent knows precisely what this tool inspects, though it never distinguishes itself from single-domain siblings like cao_bim_eclairage or cao_bim_acoustique.

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?

"Appelez quand vous devez VERIFIER LA BIBLIOTHEQUE" gives a trigger condition, and "Indicatif — CCTP tertiaire signe prime" hints at the context in which the result matters. But no exclusions or alternatives are named, which is a real gap given ~200 cao_bim_* siblings covering lighting, acoustics and furniture individually.

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, destructiveHint=false, and openWorldHint=false; 'Lecture seule' merely repeats that. The description adds meaningful context with 'Indicatif — DTU plomberie et CCTP signes priment', warning that results are indicative and normative documents govern. It does not describe return format, error behavior, or rate limits, so the added value is useful but limited.

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, beginning with the call trigger and the resource. It uses terse telegraphic notation but wastes little space. The parenthetical codes are dense but appropriate for the domain.

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-only check with one parameter and no output schema, the description covers purpose, sub-checks, indicative nature, and read-only behavior. It leaves gaps around what the check returns, how results are structured, and how incomplete scenes are handled, which matter because there is no output schema.

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% for the single nested 'scene' parameter, and the description simply restates the same structure: 'scene : bidet {robinetterie, evacuation, fixation, accessibilite}'. It adds no further meaning about expected geometry, required properties, or nested object constraints 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 uses a specific verb and resource: 'VERIFIER LE BIDET', and enumerates the four sub-checks (robinetterie, evacuation, fixation, accessibilite). It clearly scopes the tool to bidets, but does not explicitly distinguish it from nearby siblings like cao_bim_wc, cao_bim_douche, or cao_bim_sanitaires_communs.

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 phrase 'Appelez quand vous devez VERIFIER LE BIDET' gives a direct trigger condition. However, there is no guidance on when not to use it, no prerequisites, and no mention of alternative tools for other sanitary fixtures or for broader bathroom checks.

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 cover read-only and non-destructive behavior, but the description adds substantial domain behavior: the CBS formula, coefficient values, threshold checks, and the regulatory caveat. It does not contradict the annotations and adds meaningful context beyond 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 purpose is front-loaded, but the description is one sprawling semicolon-heavy sentence. It also repeats the scene field list already present in the schema and repeats 'Lecture seule' from the annotations, 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?

It explains the computation logic, thresholds, and caveat well enough for a domain check. However, with no output schema, it does not say what the tool returns (CBS value, pass/fail, individual threshold results), leaving the response shape to inference.

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 interpretive meaning by mapping land-cover fields to coefficients and explaining that the threshold defaults to 0.2 or scene.seuil_cbs. This helps the agent use the nested scene parameters correctly.

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 ('verifier la BIODIVERSITE d'une parcelle') and resource ('coefficient de biotope du PLU'), then gives the CBS formula. It is clearly distinguishable from the many generic BIM sibling 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?

Explicitly says when to call it ('Appelez quand vous devez verifier...') and gives the important caveat that the local PLU prevails. It does not name alternative tools or when-not-to-use conditions, so it falls 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known; the description adds the non-obvious caveat that results are indicative and that Eurocode 5 / signed CCTP take precedence, which meaningfully frames how to use the output. "Lecture seule" merely restates the annotation, and no return shape or coverage limits are described.

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 compact paragraph, front-loaded with the call trigger and the check categories, with no filler sentences. Minor duplication: the four checks are listed twice (as BL- codes and again in the `scene` shape).

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 read-only, single-parameter checker with no output schema, the description covers what is checked, the indicative nature of the result, and the authority hierarchy. The only gap is any hint about what the check returns (verdicts, findings, per-code status), which the agent must infer.

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% and the single nested `scene` parameter is documented in the schema with the same field list the description repeats. The description adds no syntax, units, or expected content for the nested section/fixation/appuis/protection fields, so it earns the baseline rather than 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?

States a specific verb (VERIFIER) and resource (BLOCHETS/wall blocks), then enumerates the four check families with codes (BL-SECTION, BL-FIXATION, BL-APPUIS, BL-PROTECTION), so the agent knows exactly what is inspected. It does not explicitly differentiate itself from the many neighbouring cao_bim_* check tools (e.g. cao_bim_appuis_seuils, cao_bim_ancrages), which keeps it below 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?

"Appelez quand vous devez VERIFIER LES BLOCHETS" gives a clear trigger condition, and the caveat "Indicatif — Eurocode 5 et CCTP signes priment" tells the agent the output is advisory and that authoritative documents override it. No explicit when-not or named alternative sibling 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?

Annotations already declare readOnlyHint/destructiveHint=false, and the description restates 'Lecture seule' rather than adding to it. The genuinely additive disclosure is 'Indicatif — reglement de copropriete et norme signes priment', which warns the agent that output is advisory and may be overridden by the co-ownership rules and signed standards — real behavioral context 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?

One front-loaded imperative sentence carrying the trigger, the four checked aspects with their codes, the scene shape, and the precedence caveat. The brief restatement of the scene fields is the only near-redundancy and it is compact.

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-required-parameter read tool with a nested object and no output schema, the description covers what is examined and how much to trust the result. It does not say what the returned verdict looks like or what happens if the scene lacks a boites_aux_lettres node — minor gaps given annotations carry the safety profile.

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% and the single 'scene' parameter is documented as a nested boites_aux_lettres object; the description simply re-lists the same subfields (emplacement, nombre, eclairage, protection). No extra syntax, format, or default behavior is added, 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 verb ('VERIFIER LES BOITES AUX LETTRES') and resource, and enumerates exactly which sub-aspects are checked (emplacement/acces, nombre, eclairage, protection) with their domain codes (BL-*). Within a vast family of cao_bim_* siblings, an agent can immediately tell this audits mailboxes rather than lighting, access, or bin stores.

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?

'Appelez quand vous devez VERIFIER LES BOITES AUX LETTRES (gestion locative)' gives an explicit trigger condition plus the context (rental management) in which it applies. It stops short of naming a sibling alternative or an exclusion case, so the routing guidance is clear but not exhaustive.

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 and destructiveHint=false, and the description reinforces this with 'Lecture seule'. Beyond annotations it discloses genuinely useful behavior: results are indicative and require a signed plan, and the density output carries an alert band (30-250 kg/m3). It does not describe pagination or response structure, but nothing contradicts 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 the trigger and the deliverable, then packed with high-density specifics (norm reference, formula, grouping, alert range). It is long for a single paragraph and mixes usage, computation and caveats, but nearly every clause carries information an agent needs.

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 does the work of explaining returns: grouped by element/diamètre/forme with steel total, scene concrete and kg/m3 density. What's missing is what the 'verifier' and 'formes' action modes return versus the default 'bordereau', leaving the non-default branches underspecified for a tool with 0 required params.

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 both parameters and the nested barres/dims structure. The description restates the same shape (element + barres[{diametre_mm, forme, quantite, dims}]) and the same action values, adding little new meaning beyond confirming 'bordereau (défaut)'. 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 precise verb+resource ('produire le BORDEREAU D'ARMATURES') and enumerates the concrete computations performed (développé per NF A 35-027, masse via d²×0,006165, grouping by element/diamètre/forme). It never names a sibling, so an agent cannot tell from the text alone how this differs from cao_ferraillage or cao_metres, which keeps it at 4 rather than 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?

Opens with an explicit trigger condition ('Appelez quand vous devez produire le bordereau d'armatures d'une scène') and adds the prerequisite that a signed ferraillage plan is mandatory, plus the caveat that output is indicative. No exclusions or named alternatives are given, so it stops short of 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?

Annotations already declare readOnly=true and destructive=false, so safety is covered. The description adds meaningful traits: results are indicative-only and superseded by signed contractual documents, plus it discloses that control ratios and empty lots are included in output. 'Lecture seule' merely repeats the annotation and earns no credit.

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, front-loaded sentence opening with the trigger condition, followed by the enumerated output contents. It is efficient, though the long dash-separated list of lots makes it heavy to scan.

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, so the description carries the burden of describing returns – and it does, enumerating unit types per lot plus control ratios and empty-lot reporting. Combined with the indicative-not-contractual caveat, an agent has enough to call and interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter with 100% schema description coverage, so the schema already documents the scene object (walls, slabs, roofs, openings, reinforcement). The description adds no syntax or format detail beyond that, making the baseline 3 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 a specific verb+resource: producing per-lot EXE quantity bills (concrete, formwork, steel, partitions, roofing, joinery). It clearly differs from sibling cao_bim_bordereau_armatures (steel only) and cao_metres, but it doesn't explicitly name those siblings to route the agent.

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?

'Appelez quand vous voulez les BORDEREAUX QUANTITATIFS EXE par lot' gives a context for use, but it largely restates the purpose. No when-not conditions or named alternative tools are offered; the caveat that contractual metré/DPGF prevail is a disclaimer, not routing 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?

"Lecture seule" merely restates readOnlyHint, earning no credit, but the "Indicatif — règlement départemental DECI et CCTP signés priment" clause adds real behavioral context: output is advisory and may be overridden by regulatory documents. That is the kind of caveat an agent cannot infer from 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?

The trigger is front-loaded in the imperative, and the enumeration of check codes is compact. Slight redundancy between the check list and the scene field list, but every element 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?

For a read-only, single-parameter tool with no output schema, the description supplies the scope of checks and the authority caveat. Only the shape of a valid scene entry beyond field names is left implicit.

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 single nested param is already documented, so the baseline is 3. The description repeats the borne_incendie sub-fields rather than adding format, value constraints, or expectations about what a populated scene looks like.

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?

Names a specific verb (VERIFIER) and resource (borne / poteau incendie), then enumerates the exact sub-checks (débit, accès, signalisation, entretien) with their code identifiers. It does not explicitly distinguish itself from nearby siblings like cao_bim_incendie or cao_bim_detection_incendie, but the resource is narrow enough to be 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?

"Appelez quand vous devez VERIFIER LA BORNE" gives an explicit invocation trigger, and the caveat that departmental DECI regulations and signed CCTPs prevail tells the agent when this tool's output is not authoritative. No alternative tool is named for the non-indicative case, which keeps it just 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?

Annotations already declare readOnlyHint/destructiveHint=false, so 'Lecture seule' is partly redundant. The real added value is the caveat that results are indicative and that the signed IRVE decree and NF C 15-100 prevail — a normative-authority warning not present in any structured field. It stops short of saying what findings or severity levels are returned.

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 call trigger and the four checkpoints, with no filler. Slight redundancy: the checkpoint list is given in prose and then again as the schema mirror, which costs a few words without adding 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?

Covers scope, the four verification axes, the non-normative status, and the safety profile — enough to invoke correctly with a single scene object. With no output schema, the description would ideally hint at what a verification produces (findings, conformity verdict), which is the remaining 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?

Only one parameter, and schema coverage is 100% with the same wording ('bornes_recharge {alimentation, protection, emplacement, comptage}') repeated verbatim in the description. Baseline 3 applies since the schema already carries the semantics and the description adds no format or shape guidance.

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 (VERIFIER) and resource (bornes de recharge VE / IRVE) and enumerates the four checkpoints it covers (BR-ALIMENTATION, BR-PROTECTION, BR-EMPLACEMENT, BR-COMPTAGE). An agent can tell this apart from generic siblings like cao_bim_comptage or cao_bim_circuits_electriques 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?

The opening 'Appelez quand vous devez...' gives an explicit trigger condition, which is exactly what an agent needs to route here. It does not, however, name exclusions or alternatives (e.g. that comptage/supervision alone belongs elsewhere), so there is no when-not guidance.

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