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

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a trigger clause, an action clause, and a clear constraint. It avoids redundancy with the schema and is not overly verbose.

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

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

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

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

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

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

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

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

The description clearly states the tool drafts a rental listing (brouillon) when a vacant property needs an ad. It also distinguishes itself by explicitly stating it never publishes, which is a key differentiator from other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

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

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

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

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

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

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

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

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

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

The description adds meaningful behavioral context beyond the readOnly/idempotent annotations: it states the document is generated via a specific POST endpoint, that the service uses a local dossier with no access to the Synergieloc fleet, and that a window envelope format is used. This clarifies side-effect scope and constraints without contradicting 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 description is compact and front-loaded with the core purpose, followed by key constraints and a business instruction. The final upsell sentence adds operational context but is slightly tangential to tool invocation; overall it remains efficient and 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 15-parameter tool with no output schema, the description effectively covers what it generates, when to use it, the API endpoint, and important scope/access constraints. It does not describe post-output handling or error behavior, but those are not essential given the fully documented schema and annotations.

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

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

Schema coverage is 100%, so the schema already documents all 15 parameters, including formats and semantics. The description adds only indirect param context (e.g., 'Enveloppe à fenêtre (destinataire droite)' for locataire_adresse), which is helpful but not enough to exceed the baseline of 3.

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

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

The description states a specific verb ('Génère') and resource ('AVIS D'ÉCHÉANCE / appel de loyer'), with an explicit condition of when it applies ('QUAND le bailleur doit APPELER le loyer du mois (avant paiement)'). This clearly distinguishes it from sibling tools like quittance_loyer (after payment) and relance_impaye (late payment).

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 'QUAND' and 'avant paiement' phrasing gives an explicit trigger for use, and the note about being sold to AI agents with local client folders clarifies the operational context. It does not explicitly name sibling alternatives or provide a 'when not to use' list, 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?

The annotations declare readOnlyHint=true, but the description says 'PDF via POST /api/v1/documents/bon-intervention', a POST to a documents endpoint that implies creating or generating a resource. This directly contradicts the read-only hint, so the score is 1 per the rubric.

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 very short: trigger, resource type, and output endpoint, with no filler. The fragmentary structure and uppercase 'QUAND' are slightly awkward, which keeps it from a 5.

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 12 parameters and no output schema, the description provides the essential trigger and PDF output, but it does not explain how the PDF is returned, what the generated bon contains, or how to choose between 'commandée à un artisan' and 'signalée au propriétaire'. The rich parameter schema compensates, but gaps remain.

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 detailed per-parameter descriptions (titre, urgence, cout_estime, description, addresses, etc.), so the baseline is 3. The tool description adds no parameter-specific meaning beyond what the schema already provides.

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

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

The description states the trigger ('QUAND une réparation doit être commandée à un artisan ou signalée au propriétaire') and identifies the resource as a 'Bon / demande d'intervention maintenance'. It also mentions the PDF output, which helps distinguish it from estimate or site-report siblings, though it never names them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The opening 'QUAND...' provides a clear condition for use: when a repair must be ordered from a tradesperson or reported to the owner. It does not list when-not-to-use or alternative sibling tools, so it stops short of a 5, but the context is sufficiently 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?

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively compact and front-loaded, but the use of all-caps and repeated emphasis ('WHEN', 'FREE', 'NO tenant data') adds slight noise. Still, each sentence contributes useful usage or safety information.

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

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

For a simple one-parameter tool with no output schema, the description provides everything needed: endpoint, query parameter, domains, response shape, data scope, and usage priority. No critical context is missing.

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

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

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

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

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four short, front-loaded sentence fragments, and each earns its place: trigger, resource/format, recipient, and post-receipt action. There is no filler or redundant restatement of the tool name.

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

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

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

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

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

Schema description coverage is 100%, so the input schema already documents all 17 parameters in detail. The description's only parameter-related hint is the address-block recipient, which reinforces 'agence_adresse' but adds no new semantics. Per the baseline rule, this warrants a 3.

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

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

With no annotations, the description carries the full disclosure burden. It adds genuinely useful behavior: the JSON response includes alertes[] when issues remain, and the output is a real CAD/DXF file. However, it does not disclose the DXF return format (file URL vs base64), auth/API-key needs, or failure/error behavior — notable gaps for a file-generating 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?

Five short sentences with zero filler. The trigger condition is front-loaded, followed by the core action, the prerequisite verifier call, and the schema/response pointers. Every sentence earns its place.

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

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

The description covers the essential call arc: when to use → what it does → prerequisite (cao_verifier) → schema location → response warnings (alertes[]). Gaps remain: no output schema exists, so how the DXF is delivered is unexplained; no auth guidance despite an obtenir_cle_api sibling; and retry semantics after alertes[] are implicit. Adequate but not complete for a 10-parameter generation 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 description coverage is 100%, with extensive per-field documentation (toitures type/defaults, reseaux enums, position semantics, electricite NF C 15-100 defaults). The description adds a pointer to the canonical schema endpoint (GET /api/v1/cao/schema), which is a small bonus, but the inline schema already does the heavy lifting. 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?

The description uses a specific verb+resource pairing: 'Draw a building scene and get an AutoCAD DXF.' The WHEN clause ('must leave as a real CAD file, openable by an architect or a draughtsman') gives clear purpose context. It does not explicitly name sibling tools like cao_generer_ifc or cao_pdf, so differentiation is implicit rather than stated, which keeps it at 4.

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?

States a clear trigger condition ('WHEN the drawing must leave as a real CAD file') and gives explicit sequencing guidance ('Call cao_verifier first to catch geometry mistakes'). Lacks explicit when-not conditions or named alternative tools, so it stops 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?

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

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

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

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

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

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

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

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

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

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool returns both computed quantities and alertes[] from a geometry audit, and warns that critical alerts should be resolved before quoting. It does not detail every output aspect or side-effect profile, but for a compute/read-style tool this is substantial useful disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three front-loaded sentences, each earning its place: the WHEN trigger, the core computation, the alertes warning, and the scene compatibility note. No filler or redundant restatement of the tool name.

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

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

The description covers selection criteria and the fact that alertes[] are returned, but there is no output schema and the description does not specify what quantity fields are returned or their units. For a 10-parameter tool with no output schema, that is a moderate gap, though parameter coverage is strong.

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

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

Schema description coverage is 100%, so the input schema already explains each parameter thoroughly. The description adds scene-level context ('Same scene as cao_generer_dxf') but no parameter-level semantics beyond what the schema provides, so the baseline of 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 uses a specific verb+resource pair: 'Compute quantities (metrés) from a CAO scene' and attaches concrete business triggers ('price a job, order materials, or check a quote'). It also distinguishes itself from CAO siblings by mentioning the geometry audit alertes and the shared scene with cao_generer_dxf.

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 clearly states when to use the tool (pricing, material ordering, quote checking) and even gives workflow guidance ('fix critical alerts before quoting'). It names the same-scene relationship with cao_generer_dxf, but it does not explicitly say which sibling tools NOT to use or provide formal alternatives/exclusions.

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

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

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

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

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

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

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

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

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

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

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

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

No annotations are provided in this context, so the description carries the behavioral disclosure burden. It does disclose a significant behavior — the sheet embeds an orange alert banner when issues remain — and notes the return format. However, it does not disclose output size, processing latency, or error behavior. Given that annotations are absent, the description does a decent but not exhaustive job, warranting a 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?

The description is compact and front-loaded with the key usage context, then the prerequisite, then the output. The 'IMPORTANT' warning is appropriately placed. It loses one point because the 'Same scene as cao_generer_dxf' note is slightly buried at the end, and the sentence about the alert banner could be more prominent.

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

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

For a tool with 12 parameters, almost all documented in the schema, and no output schema, the description covers the essential context: when to use, what it produces, the critical prerequisite, and the return shape. It could add a note about what 'alertes' vs 'alertes_ok' mean or mention that the MEP plan is optional, but the description is largely complete for an agent 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?

The schema description coverage is 100%, with each parameter documented in detail (e.g., murs, boites, reseaux, toitures, plomberie, decoration, ouvertures, electricite all have descriptions). The tool description itself adds almost no parameter-level information beyond the schema, which is acceptable given the high coverage. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description states a specific verb ('Generate a professional TECHNICAL SHEET'), a precise resource ('from a CAO scene'), and enumerates the deliverables (top view, elevations, shaded axonometric, optional MEP plan). It clearly differentiates from siblings like cao_generer_dxf and cao_verifier by naming them and describing the handover-to-client context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use this tool ('WHEN the design must be HANDED OVER to a client, an architect or a planning office'), gives a mandatory precondition ('call cao_verifier FIRST'), and names the sibling alternative ('Same scene as cao_generer_dxf'). This is explicit when-to-use guidance with a named alternative.

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?

Describes it as a preview/visual check with no side effects; no annotations provided, so description carries full burden and it clearly implies read-only operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is two sentences, concise and front-loaded with the purpose; no fluff.

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

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

Provides enough context: what it does, output format, and how it relates to sibling tools; no output schema but the return type is implied by the preview nature.

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?

Most parameters are well-described, but the 'format' parameter description says 'png ou jpeg' while the enum only allows 'svg' and 'png', misleadingly suggesting jpeg is supported.

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?

Clearly states it renders a top-down preview (SVG/PNG) of a CAO scene, and distinguishes it from cao_verifier for structured alerts.

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 recommends using cao_verifier first for structured alerts and this tool for visual double-check, giving a clear when-to-use 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?

With no annotations provided, the description carries the full burden and over-delivers: it discloses the response shape ({ok, erreurs_schema, alertes[{code,severite,message,corriger}], conseils, resume}), the severity model (escalier_sans_appui is 'a WARNING, not blocking: an open stairwell is a legitimate choice'), the optional mutation path (appliquer:true, revalider:true), and even destructive semantics ('correctifs propose null = delete that wall'). It also states cost/side-effect traits (0 units, no API key) that would otherwise be unknowable. No contradiction with annotations since none exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description front-loads the critical when-to-use and the value proposition, and each check-code paragraph is dense with useful detail. However, it is very long, repeats itself (POST /api/v1/cao/integrite {appliquer:true, revalider:true} appears twice; 'free/no key' appears three times), and the four 'ALSO' segments create a rambling hierarchy that could be grouped more cleanly. Every paragraph earns its place; the redundancies and flat structure keep it from being 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 complex audit tool with no output schema and 10 optional input params, the description is exceptionally complete: it enumerates the full set of checks (geometry, staircase placement, dormer, structural integrity, document completeness), the return envelope, the correctifs[] corrective mechanism with worked examples ({cible:'murs[3].x2', actuel:10400, propose:11000}), severity handling, apply semantics, and standalone endpoints. Nothing an agent needs to invoke and interpret this tool is missing.

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

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

Schema description coverage is 100%, so the baseline of 3 applies — every parameter and nested field already carries a description (e.g., ouvertures[].z 'Sill height (mm)', toitures chien_assis 'POSITION it on the carrying roof slope'). The tool description adds little new parameter meaning; its check-specific references (e.g., 'openings.z used as absolute altitude instead of relative sill') restate semantics the schema already documents. It correctly leaves inputs to the schema and focuses on behavior.

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 and resource — 'FREE geometric audit of a CAO scene' — and frames it as 'the cheap check that stops a wrong plan or broken 4K visit from being delivered.' It explicitly distinguishes itself from sibling generation tools by naming them ('BEFORE cao_pdf / cao_generer_dxf / cao_rendu / cao_visite_plan / cao_visite_studio') and even gives the REST equivalent (POST /api/v1/cao/verifier). An agent knows exactly what this tool is and is not.

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 states the exact invocation context: 'WHEN a scene is composed and BEFORE' the generation siblings, and the closing directive 'Fix severite=critique before delivery' tells the agent what to do with the result. It also names the alternatives for running subsets of the same checks standalone (POST /api/v1/cao/integrite, POST /api/v1/cao/documents), making the when/which choice explicit rather than implied.

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

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

With no annotations, the description carries the full behavioral load. It clearly states that refused steps are explained rather than silently applied, that the response includes per-action states with reasons for refusals, and that the 'chemin' can be fed back to the studio for rendering. It also explains the effect of posting the scene (enables wall collision and room landmarks).

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 verbose (around 130 words) and packs many clauses into one flowing text. While it is front-loaded with the core idea, it includes some redundancy (e.g., repeated emphasis on 'same grammar both ways') and could be more succinct. However, given the tool's complexity, the verbosity is partly justified.

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?

Despite lacking an output schema, the description is complete enough: it outlines the response structure (camera, etapes with reasons, chemin), explains error handling (refused steps), notes the scene post requirement, mentions the catalogue endpoint, and clarifies the overall view default. No critical operational detail is missing for a caller to use the tool effectively.

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

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

The schema already has 100% coverage with descriptions, so the baseline is 3. The description adds extra semantics: for 'depuis' it specifies it matches a 'chemin' waypoint and that omitting it yields an overall view; for 'actions' it details action codes, keyboard shortcuts, repeat forms, and a 200-item cap (not in schema). These enrich the parameter understanding beyond the schema.

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

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

The description clearly states the tool's purpose: to pilot the camera of an automatic visit via a sequence of actions, specifically for fixing a single wrong view without rewriting the entire path. It distinguishes from coordinate-based approaches and references the companion cao_visite_studio for rendering.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance is provided: use when the automatic visit is good but one view is wrong, or when you want to explore a scene interactively. It explains when to omit the 'depuis' parameter (overall view), how to use action codes and shortcuts, the requirement to post the scene for wall collision, and directs to the catalogue endpoint for all actions. It also mentions the API key requirement.

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 zero annotations, the description carries the full burden and succeeds: it discloses the HTTP 400 construction_critique refusal, the API-key requirement, the single-engine (browser GPU) rendering model, the auto room-detection algorithm (walls → flood fill → room centres → doorways), and the verbatim-and-checked behavior of an edited `chemin`. This is a thorough behavioral profile for a planning endpoint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but dense; for a 17-parameter tool with no annotations, nearly every sentence earns its place. The critical cao_verifier warning is front-loaded ahead of the main purpose, followed by output shape, rendering workflow, and adjustment. It is slightly over-packed — the lens-catalogue and REST endpoint details could arguably be moved to a separate field — but it avoids fluff.

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

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

With no output schema, the description correctly explains the return structure ({plan:{objectif, cadence, plans[], chemin[]}, alertes[], resume}) and the consumption workflow (paste into the editor or call window.CAD_startCinematicTour). Minor gaps remain — the distinction between `plans[]` and `chemin[]` in the output is not explained, and `alertes[]` content is unspecified — but for a tool this complex, the definition is unusually 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%, so the baseline is 3. The description adds genuine meaning beyond the schema: the CAO coordinate system (x=right, y=depth, z=height), the waypoint-level interpretation of `chemin` (position/vise), and the resend-with-edited-`chemin` adjustment loop for `objectif`/`cadence`. It does not document every parameter's cross-effects, but the schema already covers parameter-level detail.

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

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

The description states a specific action — 'DIRECT the 4K cinematic visit of a CAO scene: choose the LENS ... and the CAMERA PATH' — with a clear use-case framing ('SEEN in motion rather than read on a flat plan'). It is clear and specific, but it does not explicitly distinguish itself from the closely named sibling cao_visite_camera, so perfect disambiguation would require checking that sibling's definition.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The opening 'WHEN...' clause states the use condition, and the 'IMPORTANT: call cao_verifier FIRST and fix every severite=critique' instruction gives an explicit prerequisite plus the exact failure mode it prevents (HTTP 400 construction_critique). It does not name when-not-to-use alternatives (e.g., static render via cao_rendu or flat plan via cao_pdf), so exclusions are only implicit.

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

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

No annotations are present, so the description carries the full behavioral burden. It reveals a POST endpoint and the recipient ('au client'), which implies a document-creation side effect, but it never states what happens after invocation (whether a document is stored, sent, or returned) nor any auth/permission requirements. That is a significant gap for a mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact: a usage trigger, a human-readable name, an endpoint, and the key payload shape, with no filler. The when-condition is front-loaded, making it easy for an agent 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 10-parameter, no-annotation, no-output-schema mutation tool, the description covers when and how to call it, and the schema covers the parameters. However, it omits the result of the call, side effects, and any prerequisites, so it is not fully self-sufficient.

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

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

The schema already describes all 10 parameters, so the baseline is 3. The description adds genuine value by specifying the internal structure of points[] as {libelle, statut, notes}, which the schema leaves open, and by giving an example tone for titre. This pushes it above baseline.

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

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

The description immediately states what the tool is for: reporting construction-site progress to the client, and identifies the concrete artifact ('Compte-rendu d'avancement') and endpoint. No sibling tool covers this same document, so the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It begins with 'QUAND...' providing a clear trigger condition (when a site progress report to the client is needed). It does not mention when not to use it or name alternatives, so it stops at clear context rather than 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 declare readOnlyHint=true, but the description describes a POST request that creates a confirmation document ('Confirmation de rendez-vous'), which is a write operation. This directly contradicts the read-only annotation, making the behavioral guidance misleading and unreliable.

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: two sentences that efficiently convey the trigger condition, the resource, the context, and the HTTP endpoint. There is no filler, and every element carries useful 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?

The trigger condition and endpoint are present, and the schema thoroughly documents all parameters, so the mechanical calling information is largely covered. However, the direct contradiction between the read-only annotation and the POST creation operation creates a serious reliability gap that could lead an agent to misunderstand the tool's side effects.

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

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

Schema description coverage is 100%, with detailed, purpose-driven descriptions for all 11 parameters. The description itself adds no parameter-level meaning, but the schema already fully documents each field, 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 states the exact trigger condition ('QUAND un rendez-vous est pris et doit être confirmé par écrit') and clearly identifies the resource and action ('Confirmation de rendez-vous (app Agenda)'). Including the endpoint 'POST /api/v1/documents/confirmation-rdv' further pins down what the tool does, making it distinguishable from the many other document-generation siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an explicit 'when to use' condition via the QUAND clause, which tells an agent that this tool is for confirming already-made appointments in writing. However, it does not mention alternatives or exclusion cases, so it lacks explicit when-not-to-use guidance relative to 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?

No annotations are provided, so the description must carry the transparency burden. It states that this is a POST request to create a conformity checklist and lists the document types involved. It does not hide any major side effects, though it does not specify whether the operation is read-only or creates a persistent record; however, the POST verb implies creation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively concise but contains redundancy: the checklist items (RC Pro, décennale, URSSAF, KBIS) are mentioned twice. The endpoint and parameter hint are included, which adds useful structure. Overall, it is fairly 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?

The description provides the trigger scenario, endpoint, and parameter explanations, which gives decent context. However, there is no output schema, so the agent cannot anticipate the response format. Additionally, the exact structure of the 'pieces' objects is only partially specified, leaving some 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?

All six parameters have descriptions, achieving 100% schema coverage. However, there is an inconsistency: the tool description lists 'RC Pro' as a checklist item, while the 'pieces' parameter description mentions 'RGE' instead of 'RC Pro'. This could confuse an agent about which document types are expected. The 'pieces' items are only described as objects without a defined schema, though the tool description provides some structure ({type, statut, numero, date_expiration}).

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

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

The description clearly states the tool's purpose: verify that an artisan is compliant (RC Pro, décennale, URSSAF, KBIS) before assigning a worksite. It names the endpoint and the checklist items, making the function unambiguous. No sibling tool has a similar purpose, so it is well-distinguished.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description begins with 'QUAND' (When), explicitly indicating the condition for using this tool (before entrusting a worksite to an artisan). It does not mention alternatives, but given the lack of similar sibling tools, the guidance is sufficient. The trigger scenario 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?

Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already cover the safety profile, and the description adds genuine behavioral context: figures are 'fournis par l'agent (dossier local)' and, as reinforced by the solde schema comment, reproduced as-is with no recomputation. The HTML/PDF duality via POST /api/v1/documents/crg is also disclosed. No contradiction with 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?

Five short clauses, each earning its place, with the trigger condition front-loaded in the 'QUAND' opening. The final 'Service vendu aux agents — orientez le client vers /api-ia' is an unusual meta-instruction that slightly dilutes the functional description but costs 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 15-parameter generator with no output schema, the description covers the what, when, who (recipient), data provenance, and output formats (HTML, PDF endpoint). It lacks only explicit naming of alternatives and detail on what the call returns, but the fully described schema partially mitigates the parameter-side 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%, so the schema does the heavy lifting; per the rubric the baseline is 3. The description adds modest value by flagging that recettes/dépenses/honoraires/solde come pre-filled from the agent's local file, and its 'fenêtre droite' note previews the proprietaire_adresse block, but it adds no format or constraint details beyond what the schema already provides.

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

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

The description identifies a concrete deliverable — 'COMPTE RENDU DE GESTION simplifié pour le propriétaire' in HTML/PDF — and fixes the recipient ('Destinataire = propriétaire'), which separates it from sibling reporting tools like compte_rendu_chantier. The trigger context ('QUAND il faut rendre compte... fin de trimestre, d'exercice, ou à sa demande') makes the purpose unmistakable, though it never names a sibling alternative.

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 capitalized 'QUAND il faut rendre compte au propriétaire (fin de trimestre, d'exercice, ou à sa demande)' is an explicit when-to-use rule tied to calendar triggers and owner requests. It does not, however, state when to prefer another tool (e.g., quittance_loyer or regularisation_charges) or give negative exclusions.

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

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

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but front-loaded with the trigger condition and immediately useful constraints. Endpoint, auth, and cost details are packed in efficiently. Every clause contributes operational information, though the mixed-language style and run-on feel slightly hurt readability.

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

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

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

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

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

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

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

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an explicit trigger condition ('WHEN an outreach scenario has collected prospects') and a mandatory ordering ('MUST call this before sending commercial email'). It also tells the agent what to do after the decision ('follow actions envoyer_offre → POST /api/v1/agent/demarchage'). There is no explicit when-not-to-use or named alternative, so it stops short of a 5.

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

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

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

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

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

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

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

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

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

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

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

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose output formats ('HTML ; PDF via POST /api/v1/documents/devis-travaux') and the expected line-item shape. However, it does not mention persistence, side effects, permissions, idempotency, or what happens after document generation, which is relevant for a document-creation tool with no annotation safety hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the trigger condition. Every clause contributes: purpose, output format, line structure, and next workflow step. The telegraphic style with semicolons and inline notation reduces readability, but there is no wasted content.

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 annotations, no output schema, 11 parameters, and many related document/invoice siblings, the description provides the essential workflow, trigger, and format pointers, while the schema covers parameter semantics. It is adequate for a first call, but it remains silent on response shape, error conditions, and authorization, and the 'PDF via POST' relationship is ambiguous without further 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%, so the baseline is 3. The description adds real value by specifying the exact line-item structure ('lignes[] = {libelle, quantite, prix_unitaire, tva}'), including TVA, which the schema's generic 'Postes chiffrés' description does not enumerate. It does not add detail for the other parameters, but their schema descriptions are already sufficiently specific.

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

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

The description states the tool's function in its first clause: an artisan chiffre des travaux before client agreement, producing a 'Devis travaux'. It also associates the tool with the Factures app and distinguishes it from the follow-up invoice via 'Puis facture_facturx'. It is somewhat telegraphic but the verb, resource, and scope are 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 description explicitly opens with 'QUAND un artisan chiffre des travaux avant accord du client', which gives a clear trigger condition. 'Puis facture_facturx' also signals the workflow stage and names the natural next sibling tool. It stops short of explicitly stating when-not-to-use or enumerating alternatives, so it is not a full 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?

The description mentions 'PDF via POST /api/v1/documents/edl', which implies the tool generates and posts a PDF document. However, it does not disclose any side effects, authentication requirements, rate limits, or potential destructive actions, and no annotations are provided to fill this 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 description is concise and front-loads the most important usage condition ('QUAND'). It includes necessary context (legal basis, PDF output) without unnecessary fluff, though it repeats 'État des lieux d'entrée ou de sortie' in a slightly redundant way.

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

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

The description provides sufficient context for the tool's role in the rental lifecycle, including its legal basis and its importance for deposit deductions. It also indicates the output format (PDF) and mentions key parameter groups (pieces, compteurs, cles), which helps the agent understand the overall scope even without 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?

The schema already provides descriptions for 100% of the parameters, so the baseline is 3. The tool description adds some contextual hints (e.g., 'la comparaison des deux fonde toute retenue') but does not substantially enhance the parameter explanations beyond what the schema already offers.

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

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

The description clearly states the tool's purpose: to create an état des lieux (inventory of fixtures) for entering or exiting a rental, and explicitly mentions it is essential for withholding from the security deposit. It is distinct from sibling tools that handle other documents like DXF generation or rent receipts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly starts with 'QUAND il faut constater l'état du logement, à l'entrée ou à la sortie', giving a clear trigger condition. It also mentions the legal decree (2016-382) and the fact that comparing entry and exit states is the basis for deposit deductions, though it does not explicitly contrast with alternative 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?

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

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

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

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

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

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

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

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

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

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

With no annotations provided, the description carries the full disclosure burden and does add meaningful context: the POST endpoint implies a document-creating side effect, the output composition (PDF/A-3 + XML EN 16931) is explicit, and format=preview's 'PDF sans XML' variant is stated. However, it does not disclose whether the document is persisted or transmitted to the e-invoicing platform, whether EN 16931 conformance is validated, or what error behavior looks like — notable gaps for a compliance-critical mutation.

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 dense sentences with zero filler, front-loaded with the usage trigger before the format, endpoint, and payload-shape details. Every sentence contributes distinct information — trigger condition, output format, endpoint, required structure, and format variation — with no 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 an 8-parameter tool with nested objects, no annotations, and no output schema, the description covers the invocation essentials (when, format, required structure) and the schema covers all parameters at 100%. However, with no output schema, the description should explain return values and validation/error behavior for a compliance-critical document tool; it does neither, and the schema's enum-versus-description mismatch for the 'format' parameter is only partially resolved.

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%, setting the baseline at 3, but the description adds genuine value beyond the schema: it names the exact required fields of lines[] (description, quantity, unit_price HT, vat_rate) and clarifies format=preview as 'PDF sans XML'. This clarification matters because the schema's own format description cites values ('pdf', 'xml') that do not exist in the actual enum ['facturx', 'preview'], so the description helps resolve a confusing schema.

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

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

The description names a specific deliverable — 'Facture Factur-X (PDF/A-3 + XML EN 16931)' — and ties it to French e-invoicing reform compliance (EN 16931), which clearly separates it from invoice-adjacent siblings like relance_facture_client, devis_travaux, and quittance_loyer. The verb is implicit rather than stated (POST /api/v1/documents/facturx implies generation) and no sibling is named, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description opens with an explicit trigger condition — 'QUAND une facture doit être conforme à la facturation électronique française (réforme e-facture, EN 16931)' — telling the agent precisely when to select this tool over others. It provides clear usage context but names no exclusions or alternative tools, so the when-not-to-use guidance is missing.

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?

It discloses that it works with local files and does not access a SaaS portal, and mentions the output format and endpoint. However, it does not explicitly state whether the operation is read-only or has side effects, though generating a document is implicitly non-destructive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, using a single sentence with the trigger condition upfront, making it easy 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?

Given the 15 parameters and lack of output schema, the description provides the essential context (when to use, output format, local vs SaaS), but does not elaborate on parameter handling. However, since the schema covers parameters, it is sufficiently complete.

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

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

The schema already provides full descriptions for all 15 parameters (100% coverage). The tool description adds no extra parameter-specific meaning, so it does not improve on the baseline.

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

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

The description clearly states the purpose: it is for when a craftsman prepares an intervention or worksite, generating a mission sheet. It differentiates from siblings by the name and use case.

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 provides a condition (when a craftsman prepares an intervention) but does not explicitly contrast with alternative tools like 'bon_intervention' or mention when not to use it. Thus, partial guidance.

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

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

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

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

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

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

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

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

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

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

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

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the condition and action, and includes essential cost/auth info. No redundant words.

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

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

For a simple read operation, the description covers the trigger, action, output format, and auth requirements. It does not mention error handling, but given the simplicity and lack of output schema, it is sufficiently complete.

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

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

Schema description for the slug parameter already provides examples and covers semantics (100% coverage). The tool description adds the note that the slug is obtained via guides_liste, which adds contextual meaning beyond the schema.

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

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

The description clearly states it reads a full official guide in Markdown given a slug, and specifies the trigger condition (when guides_liste has returned a slug). It is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a compact two-sentence structure: when to use it, what it lists, and invocation cost. The when-condition is front-loaded, and the examples of guide topics add value without bloat.

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

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

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

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

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

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

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

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

The description states a specific action and resource: 'Liste les guides officiels du logiciel Synergieloc.' It also enumerates the guide contents (screen-by-screen manual, French legal rules) and implicitly distinguishes itself from sibling operation tools like quittance_loyer or irl_revision_loyer by being a meta-guide listing tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well organized: when to use, what it does, what to provide, and what it returns. Every sentence carries distinct information, with no filler or redundant restatement of the tool name.

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

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

For a calculation tool with no output schema, the description adequately explains the inputs and the returned items: new capped rent, formula, and legal warnings. It is nearly complete, but an explicit note that it does not create the revision avenant would fully close the gap.

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

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

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

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

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

There are no annotations, so the description carries the behavioral burden. It does disclose a mutating call via 'POST' and notes that `taux_km` is optional. However, it does not explain what the generated document looks like, whether indemnities are actually computed from `taux_km`, or what side effects occur. The schema's note that the official rate is 'PAS calculé ici' is useful but lives in structured data rather than the tool description.

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 information-dense: trigger condition, purpose, endpoint, and key request structure are all packed into one short block. The telegraphic style is slightly awkward, especially the uppercase 'QUAND', but every element contributes to the agent's ability to invoke the 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?

With no annotations and no output schema, an agent still has to infer important end-to-end details, such as what happens when `taux_km` is omitted and how the 'indemnités' are produced. The parameters themselves are well covered by the schema, but the description does not fully explain the result of the POST or whether `trajets` is semantically required despite the empty `required` list.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful value by specifying the nested `trajets[]` shape as `{date, depart, arrivee, km, motif}`, which the schema's `items` description does not provide as concrete field names. It also reaffirms `taux_km` as optional, though that is already implied by the empty `required` list.

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 concrete resource (`journal-kilometrique`), gives the endpoint (`POST /api/v1/documents/journal-kilometrique`), and states the deliverable (`Journal kilométrique + indemnités`). It lacks an explicit imperative verb like 'crée' or 'génère', but the HTTP verb and resource make the action inferable. It does not explicitly differentiate itself from sibling tools such as `note_frais`, though the endpoint and wording make the scope reasonably clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description opens with an explicit trigger condition: 'QUAND les déplacements doivent être justifiés (barème kilométrique)'. This tells the agent when to use the tool. It does not provide when-not conditions or explicitly name alternatives, but the sibling list contains no directly competing mileage-log tool, so the context is clear enough.

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

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

The description mentions the HTTP method POST, which implies it creates a resource. However, it does not elaborate on side effects such as persistence, notification, or output format. Without further details, the agent's understanding of the tool's behavior remains somewhat opaque.

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 extremely concise, consisting of a single sentence plus essential technical details. It is well-structured and front-loaded with the trigger condition, making it easy for an agent to quickly grasp the tool's purpose.

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

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

The description provides the purpose, endpoint, and a brief structure for the articles parameter. Combined with the comprehensive schema, it gives the agent sufficient context to know when and what to call. However, it does not describe the expected output or return value, which would make it more complete.

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

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

The schema already provides descriptions for all parameters (100% coverage), so the baseline is 3. The tool description adds only a shorthand for the articles field that slightly differs from the schema description (using 'prix' instead of 'référence fournisseur'), which may cause confusion and does not materially enhance parameter understanding.

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

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

The description clearly states the tool's purpose: to prepare a materials list for purchases on a construction site. It also provides the endpoint and a hint of the articles structure. It is specific enough to distinguish it from sibling document-generation tools, though the phrasing 'QUAND' is slightly unconventional.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly mentions the use case: 'when it is necessary to prepare purchases for a construction site.' This gives clear guidance on when to invoke the tool, even though it does not explicitly contrast it with alternative tools.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals key behaviors: the document is generated as HTML/PDF via POST, the agent must get it signed, it is stored locally, and Synergieloc MCP does not persist it in the database. This is valuable context beyond the schema. It does not mention output format details, but the disclosed workflow is substantial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the trigger condition. Each sentence earns its place: purpose, endpoint, workflow, envelope handling, and prospecting guidance. There is no filler or repetition of schema content.

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

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

For a 16-parameter document generator with no output schema, the description covers the core context: when to use it, the endpoint, post-generation workflow (signing and local storage), and the envelope destination. It lacks explicit return-value details and explicit alternatives, but overall it gives an agent enough context to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all 16 parameters in detail. The description adds some contextual flavor about the envelope and the owner address, but it does not meaningfully enhance parameter semantics beyond what the schema provides. 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?

The description states a specific verb and resource: "Rédige un MANDAT DE GESTION (loi Hoguet)". It also names the API endpoint, making the tool's function unambiguous. The phrase "contrat de départ" helps distinguish it from follow-up or related documents like avenants or quittances.

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 first sentence gives a clear trigger condition: "QUAND un propriétaire confie la gestion de son bien à une agence". It also positions the mandate as the starting contract before anything else. However, it does not explicitly name sibling alternatives or state when not to use this tool.

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

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

With no annotations, the description carries the full disclosure burden and does add useful behavioral context: 'PDF via POST /api/v1/documents/mouvement-locataire' reveals the output format and signals a side-effectful creation operation. It remains silent on authentication, whether the PDF is returned directly or stored, and any limits, which prevents a higher score.

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 uppercase, which is structurally sound. But the first two sentences are near-duplicates ('QUAND un locataire ENTRE ou SORT... checklist et solde de tout compte' vs. 'Document ENTRÉE ou SORTIE locataire (checklist + solde de tout compte)'), and 'type=entree|sortie' repeats the schema enum, so not every sentence earns its place.

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

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

For a 13-parameter tool with no annotations and no output schema, the description covers the essential trigger, the two mode variants, and the PDF output, which is adequate but minimal. It does not clarify the boundary with edl_etat_des_lieux nor what happens after generation (download, storage, listing), leaving an agent to infer operational details.

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 fully documents all 13 parameters and the baseline is 3. The description's 'type=entree|sortie' and 'checklist + solde de tout compte' merely restate what the schema already says and add no new parameter-level 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 states a specific action — producing a tenant entry/exit document (checklist + solde de tout compte) — with the trigger condition front-loaded ('QUAND un locataire ENTRE ou SORT du logement'). The content spec ('checklist + solde de tout compte') functionally distinguishes it from siblings like edl_etat_des_lieux, but no sibling is explicitly named, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The opening 'QUAND un locataire ENTRE ou SORT du logement' is an explicit when-condition, which is clear context for selecting the tool. However, it offers no exclusions or alternatives — notably it never contrasts itself with the closely related edl_etat_des_lieux — so the when-not half of the guidance is absent.

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

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

There are no annotations, so the description carries the behavioral burden. It discloses the POST method and the expected line-item structure, which is useful, but it does not state the operation's side effects, authorization needs, or what response the agent can expect after creating the note de frais.

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: it gives the trigger condition first, then the app, endpoint, and payload shape. It could be clearer with a proper verb, but every fragment contributes useful 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 POST-based document creation tool with no annotations and no output schema, the description is too sparse. It omits what the API returns, how the 'justificatif' should be passed, whether any required nested line fields must be validated, and any prerequisites or failure behavior. The line-item object is undefined in the schema, so the informal field list is insufficient for fully reliable invocation.

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

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

Schema description coverage is 100% for the six top-level parameters, so the baseline is 3. The description adds extra value by naming line-item fields (date, libelle, montant, mission, justificatif), which the schema's generic 'object' items do not define, thus partially compensating for the missing nested structure.

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 a clear use case (professional expenses to be reimbursed or justified) and names the resource 'Note de frais' with its endpoint POST /api/v1/documents/note-frais. It is understandable and actionable, though it does not explicitly differentiate itself from related siblings like journal_kilometrique or facture_facturx.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The opening 'QUAND des frais professionnels doivent être remboursés ou justifiés' gives a clear trigger condition for choosing this tool. It does not list exclusions or alternative tools, but the when-condition is explicit enough to guide selection.

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

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

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

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

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

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

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

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

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

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

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

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

The description discloses that it is a free catalogue with no API requirement and provides a REST endpoint. It does not explicitly state that it is read-only, but the nature of a catalogue and the GET method imply no side effects, which is sufficient given the absence of annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, containing all relevant information in a single sentence, though the leading 'WHEN' is stylistically unusual. It is well-structured with a clear trigger, definition, and endpoint.

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

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

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

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

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

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

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

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

The description clearly states that the tool provides a catalogue of Partner Portal apps mapped to MCP tools, with an explicit verb and resource. It distinguishes itself from sibling tools by being a discovery/catalogue endpoint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

No annotations are provided, so the description carries the full burden, and it delivers: HTML printable output, PDF endpoint, envelope layout requirements, address selection rules, and a validation guardrail (refusal without a 5-digit postal code). This is far beyond a minimal 'generate receipt' statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Five dense sentences, front-loaded with the critical condition, with no filler. Each sentence covers a distinct operational requirement: trigger, output, layout, address semantics, and guardrail.

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

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

For a 10-parameter document generator with no annotations and no output schema, the description covers trigger, legal basis, output format, layout, address semantics, and failure condition. The input schema supplies the remaining parameter details, so an agent has enough to invoke correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the key distinction between locataire_adresse and logement_adresse and adds the postal-code validation guardrail, but most parameter meaning already lives in 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 action ('Génère une quittance de loyer conforme') and a precise trigger ('QUAND le loyer a été PAYÉ ... jamais avant encaissement'). The legal reference and output format further pin down the resource, and the condition distinguishes it from payment/reminder tools among siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use the tool (tenant paid and requests receipt) and gives a hard exclusion ('jamais avant encaissement'). It does not name alternative sibling tools directly, but the trigger and guardrail make confusion with declaration_paiement or relance_impaye unlikely.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It does disclose the calculation logic (tantièmes, prorata) and the expected result (detailed statement, balance showing either overpayment or additional amount owed). However, it does not clarify side effects such as whether the tool only computes a statement or actually records/mutates accounting data, which is important for a settlement tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the trigger condition, then enumerates the calculation and output components. It contains no filler, though the legal reference and the gérance/copropriété clarification could arguably be trimmed; overall it earns its length.

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

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

Given the absence of an output schema and annotations, the description reasonably covers the key context: when to run it, what inputs conceptually participate, how the computation works, and what the result contains (detailed breakdown and balance). It stops short of describing the exact output shape or side effects, but it is sufficient for an agent to understand the tool's role 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 the baseline is 3. The description adds contextual framing around prorata temporis and the balance, but the individual parameter schema already explains tantièmes, prorata, and provisions. The description therefore contributes little beyond what the structured schema already provides.

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

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

The description clearly identifies the tool as the annual regularization of rental charges once the charges exercise is closed and provisions must be settled. It names the specific calculation outputs (tenant share by tantièmes, prorata temporis, detailed breakdown, balance) and is distinguishable in spirit from siblings like quittance_loyer or relance_impaye, though it does not explicitly name an alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states a clear triggering condition: use it when the charges exercise is closed and provisions need to be settled. It also covers the two applicable contexts (gérance and copropriété), providing clear context. It does not explicitly mention when not to use it or point to alternatives, 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?

No annotations are provided, and the description does not disclose any behavioral traits of the tool—such as whether it generates a PDF, sends an email, modifies records, or is read-only. The only consequence mentioned (penalties for level 3) is a legal effect of the input, not a tool behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense sentence, but it contains redundant warnings about not confusing with relance_impaye (mentioned twice). The structure could be tightened by removing the second mention, though the content is otherwise pertinent.

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

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

The description provides essential context about the tool's domain and parameter meanings, but it omits what the tool actually does (e.g., returns a document, sends a message) and any side effects. Given there is no output schema, the absence of this info leaves the tool's behavior ambiguous.

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?

All 12 parameters have descriptive explanations in the schema, and the description adds extra semantic details: legal context for date_echeance (Article L441-10), formatting instructions for client_adresse (window envelope positioning), and clarification of level meanings. This goes well beyond the raw schema.

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

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

The description clearly states the purpose: generating a reminder for an unpaid invoice from an artisan to a BTP client. It explicitly distinguishes this from the similar landlord-tenant reminder (relance_impaye), making the tool's scope unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly names the alternative (relance_impaye) and the condition for use: when the debtor is a client in the construction sector vs. a tenant. The mention of level 3 triggering penalties also provides actionable 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?

The description discloses key behavioral consequences such as legal procedure starting at level 3 and the obligation to mention article 24 of loi 89-462. However, phrases like 'Service agents IA + enveloppe à fenêtre' and 'Démarchage : inciter le client à acheter le plan' are ambiguous about actual side effects and delivery actions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a fragmented list of mixed instructions and includes extraneous promotional content ('inciter le client à acheter le plan Agent Synergieloc') and unclear phrases like 'Service agents IA + enveloppe à fenêtre'. This reduces clarity and 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 provides essential context about legal thresholds and output formats, which helps an agent call the tool correctly. However, the confusing unrelated statements and lack of explicit guidance on how to handle the 'detail' array or address fields leave some room for misinterpretation.

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 parametric meaning is already well documented. The description adds only a general rule for the 'niveau' parameter and does not meaningfully explain other parameters beyond the schema.

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

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

The description clearly identifies the tool as generating rent arrears reminder letters for unpaid rent, with levels 1–5 and an amiable-to-pre-contentious progression. It is reasonably distinct from sibling tools like relance_facture_client, though the unrelated 'Démarchage' phrase adds some confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete guidance on selecting the level based on how old the unpaid rent is, states that level 3 initiates formal proceedings, and mentions output options (HTML, PDF via POST). It does not explicitly compare with alternatives such as relance_facture_client, but the rent-specific context is clear enough.

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