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

With no annotations, the description carries the full behavioral burden. It usefully discloses the permission scope and the required text format for amounts, but says nothing about what gets created, whether the expense is a draft or final, what happens on validation failure, or how duplicates are handled. For a mutation tool this leaves major gaps.

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 short clauses, front-loaded with the purpose and then the two most consequential call details (format and linking). No filler, though the parenthetical permission note interrupts the flow slightly.

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

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

A mutation tool with no annotations, no output schema, and 8 parameters at 0% schema coverage. The description covers only two of those parameters and no success/failure behavior, so an agent lacks the context to call it confidently with all fields populated.

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 0% and there are 8 parameters, so the description must compensate. It adds real meaning for montant_ttc (text format, e.g. '240.00') and chantier_id (the site number within the account), but leaves dossier, categorie, montant_ht, fournisseur, and montant_tva completely undocumented, and does not explain the relationship between the three montant fields.

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

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

States a specific verb and resource ('Ajoute une dépense'), which cleanly separates it from the read-oriented sibling 'depenses'. It does not explicitly name an alternative or clarify how it relates to 'justificatifs_depense', so sibling differentiation is implicit rather than stated.

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

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

The description discloses the required permission (expenses:write), which is a useful prerequisite, but gives no when-to-use guidance, no exclusions, and never points to a sibling alternative. An agent must infer usage context entirely.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read ('Détail'), but never states permissions, whether `dossier` scopes/filters the lookup, what happens if the id is invalid, or what the returned detail contains. Only the legacy naming note ('ancien regroupement') is added.

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

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

A single front-loaded sentence with the resource and lookup key stated first. Efficient, though the parenthetical legacy note is marginally useful rather than essential.

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 detail tool with no output schema, no annotations, and 0% schema coverage, the description should convey what the detail response includes and how `dossier` affects it. It references the id source but omits return content and one parameter entirely, leaving real gaps.

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 0%, so the description must compensate. It clarifies `chantier_id` (the `id` field returned by the chantier list), but says nothing about the `dossier` parameter — its meaning, default, or whether it filters the result — leaving one of two parameters undocumented everywhere.

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: retrieves the detail of a single chantier identified by its account number. It implicitly contrasts with the list tool 'chantiers' by explaining that the id comes from that list, so an agent can distinguish single-fetch from list. It doesn't name siblings explicitly, so not 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 hints at a workflow — get the `id` from 'chantiers' first — which implies when this tool is used. However, it gives no explicit when-to-use vs when-not, no alternatives (e.g., marge_chantier), and no prerequisites beyond the id source.

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 usefully discloses that this is a legacy grouping kept for compatibility and that it is a read/list operation, but says nothing about the return payload, pagination, or volume, which are the traits an agent would need for a list 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?

Three tight clauses, front-loaded with the action, then filters, then the alternative-tool hint. Every sentence earns its place, though the parenthetical about legacy status could be trimmed slightly.

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 list tool with no output schema or annotations, the description covers purpose, filtering, and routing reasonably well, but it leaves the `dossier` parameter and the shape of the returned list unexplained.

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

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

Schema coverage is 0%, so the description must compensate. It explains `statut` (en_cours, termine…) and `client_id` (numéro du client dans le compte), adding real meaning, but completely omits the `dossier` parameter, leaving one of three parameters undocumented.

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

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

States a specific verb and resource ('Liste les chantiers') and adds scope context ('ancien regroupement, gardé pour compatibilité') that helps distinguish it from newer siblings like `chantier` or `marge_chantier`. It does not fully disambiguate from the singular `chantier` sibling, keeping it from 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?

Gives clear routing guidance — 'Pour la marge, préférer marge_client' — and describes filterable usage ('éventuellement filtrés par statut… ou par client'). It lacks explicit exclusions against other siblings such as `dossiers` or `chantier`, 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 full burden and does very little: it implies a read-only listing but says nothing about permissions, result volume, pagination, or what 'dossier' scoping does. Only the fact that search is optional and textual is disclosed.

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

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

A single short, front-loaded sentence with no filler or repetition. It is efficient, though its brevity is partly under-specification rather than disciplined concision.

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 two-parameter tool with no annotations, no output schema, and 0% schema coverage, the description is too thin: it leaves the 'dossier' filter and the shape of the returned client list entirely unexplained.

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

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

Schema description coverage is 0% for both parameters. The description explains 'recherche' as an optional text search, which adds some meaning, but the 'dossier' parameter is never mentioned in the description or schema, leaving half the inputs undocumented.

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

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

States a specific verb and resource ('Liste les clients') and adds the optional text-search scope, so an agent can distinguish it from the facture/depense/journal siblings at a glance. It does not explicitly differentiate from a hypothetical filtered-client sibling, but the sibling list contains no competing client 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?

Usage is only implied: listing clients with an optional text filter. There is no statement of when to prefer it, when not to use it, or which alternative to reach for, so the agent must infer 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 full burden and does well: it discloses the required permission, that the quote stays draft, that numero is null until sent and assigned on send, and that sending is never automatic. It omits error/validation behavior and return values, keeping it short of a 5.

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

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

A single dense paragraph, front-loaded with the action and state, then the parameter semantics, then the draft/numbering behavior. Information-dense with little waste, though it could be split for 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?

For an 8-parameter mutation tool with no annotations and no output schema, the description covers permissions, draft lifecycle, defaults and the nested line schema. Remaining gaps are notes/objet/dossier and any statement of what is returned, which is acceptable given no output schema exists.

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 0%, so the description must compensate and largely does: it defines client_id/chantier_id, the per-line structure {designation, quantite, unite, prix_unitaire_ht, taux_tva}, the optional prestation_id with its pricing-fallback logic, nature defaults, and validite_jours default. It leaves notes, objet and dossier undocumented, so not a full 5.

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 (crée) and resource (devis) plus the exact state produced (BROUILLON). No sibling tool operates on devis, so it is trivially distinguishable from the read-oriented list/export 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?

Clarifies the workflow context ("Le devis n'est jamais envoyé automatiquement : l'artisan le relit et l'envoie dans VoxFactura") and the required permission (devis:write), so the agent knows this only creates a draft. It gives no explicit alternatives or exclusions, but none exist among the 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?

No annotations are provided, so the description carries the full burden. It is reasonably clear this is a read/list operation and it discloses what each returned row contains (attachment to client, devis, or facture), which is valuable given there is no output schema. It omits pagination, volume, and authorization behavior, so the disclosure is only partial.

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

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

The purpose is front-loaded in the first sentence, followed by structure and filter details. It is appropriately sized for six filters, with only mild parenthetical clutter.

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 six-parameter, no-annotation, no-output-schema tool this covers most of what an agent needs — purpose, filter semantics, and partial return content. However, the dossier parameter goes undocumented and there is no note on result size or ordering, leaving clear gaps.

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

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

With 0% schema coverage the description must compensate, and it does for most parameters: client_id (client number in account), chantier (site number, legacy grouping), catégorie, and debut/fin (defined as AAAA-MM-JJ and inclusive). The dossier parameter is never mentioned, leaving one of six filters undocumented in both schema and description.

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

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

States a specific verb and resource ('Liste les dépenses (factures de frais)') and clarifies the resource type, so it can be told apart from write-oriented siblings like ajouter_depense. It does not, however, name a specific sibling or contrast its scope, 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 lists available filters but never says when to use this tool versus alternatives such as journal_achats, justificatifs_depense, or ajouter_depense. Usage is only implied by the list semantics, with no exclusions or prerequisites.

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 load and does well: it discloses the permission needed, that the result is a DRAFT, and that nothing is sent automatically (the artisan reviews and sends in VoxFactura). It omits failure behavior (unknown template, missing variables) and what identifier is returned.

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

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

Front-loaded with the action and draft status, then parameter-by-parameter notes with no filler. Dense but every clause carries information; only the unmentioned `dossier` is a gap rather than verbosity.

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 annotations and no output schema, but the description covers purpose, permission, the non-auto-send guarantee, and 3 of 4 parameters. An agent can call it correctly; the missing `dossier` semantics and return value are the remaining holes.

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 0%, so the description must compensate and largely does: `modele` (name or number, cross-referenced to `modeles_devis`), `variables` (value keyed by variable name, dates as AAAA-MM-JJ), and `client_id` (account client number, else the template's). The `dossier` parameter is never mentioned.

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

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

States a specific verb and resource ('Crée un devis en BROUILLON depuis un modèle de devis'), including the draft-state qualifier that separates it from a from-scratch creation. It does not explicitly name the sibling creer_devis_brouillon, so differentiation is implied by 'depuis un modèle' rather than stated.

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

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

Routes the agent to `modeles_devis` to resolve the template name/number, and states the required permission (devis:write). It gives clear usage context but no explicit when-not/exclusion 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 full burden. It usefully discloses an auth constraint ('Clé cabinet seulement') and the workflow ordering as a prerequisite step, but says nothing about result size, pagination, or error behavior when no cabinet key is present.

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?

Two tight sentences, front-loading the credential constraint and the returned fields before the follow-up instruction. The colon-fragment opening is slightly compressed but nothing is wasted.

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

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

For a zero-parameter read tool with no output schema, it covers what is returned, what credential is needed, and how to consume the result. Missing only volume/format details that an agent might want before calling.

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

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

The tool takes zero parameters, so the baseline is 4. The mention of the `dossier` parameter belongs to sibling tools, not this one, and is not misleading here.

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 resource (client dossiers) and enumerates the returned fields (numéro, raison sociale, SIREN), so an agent knows exactly what it gets back. It does not differentiate itself from the sibling `clients`, which an agent could easily confuse with 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?

Gives clear downstream usage: pass the returned numéro into the `dossier` parameter of other tools or set VOXFACTURA_DOSSIER. It does not state when not to use it or how it differs from `clients`, so it stops short of full alternative routing.

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

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

With no annotations, the description carries the full burden. It does disclose a genuine behavioral trait – the required permission ('Permission encaissements') – and reveals the return shape including the 'moyen' enum values (carte, virement, déclaré). However it never states that this is a read-only listing, nor how the 'limit' behaves (default 100 is only in the schema).

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

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

A single front-loaded sentence with a colon-delimited field list and a trailing permission clause; no padding. It is dense but every element is informative.

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 4-parameter tool with no annotations and no output schema, the description does cover the purpose, date format, return fields, and permission. But the dossier/limit parameters and the pagination behavior are missing, leaving the definition only partially 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 0%, so the description must compensate. It usefully gives the date format (AAAA-MM-JJ) covering debut/fin, but the 'dossier' and 'limit' parameters are entirely undocumented anywhere. Half the parameters are left opaque.

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 resource and scope: 'Factures encaissées sur une période' (invoices collected over a period), and enumerates the returned fields (facture, date, montant, moyen). This clearly separates it from siblings like factures_impayees and factures. It does not, however, explicitly name those siblings to sharpen the distinction.

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

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

The phrase 'sur une période' implies a date-range retrieval, but there is no explicit when-to-use guidance, no mention of when to prefer this over factures_impayees or journal_ventes, and no prerequisites stated. The agent gets no routing help.

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

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

No annotations are provided, so the description carries full behavioral burden. It discloses one important prerequisite ('Nécessite la permission comptabilité'), which is useful auth context. However, nothing about the output format beyond 'texte tabulé', no indication of which data is included or excluded, and no note about the year-vs-dossier scoping 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?

Very short and essentially front-loaded with purpose and prerequisite. No padding, though it is arguably under-specified rather than concise.

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 2-parameter tool with no annotations, no output schema, and 0% schema coverage, the description is too thin. It should specify the year/dossier semantics and what the export contains or excludes.

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 0% and no parameter is described in the text. The description implies 'de l'année' scoping, weakly hinting at the annee parameter, but neither annee nor dossier is explained, and their roles (e.g. filtering by folder) are left entirely to the schema.

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

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

The description names the resource (FEC – fichier des écritures comptables) and the format (texte tabulé) with a year scope, which is more specific than a bare name. However, the verb is only implied ('à remettre à l'expert-comptable') rather than an explicit action like 'exporte'. It lacks a clear action verb but the resource is 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?

There is no guidance on when to use this tool versus alternatives. It mentions it is meant for the accountant, implying a periodic/legal accounting use, but no sibling is named and no condition for use is given.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the return includes line items, which is useful, and 'Détail' implies a read operation, but it says nothing about permissions, the optional `dossier` scope, or what happens with invalid ids.

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

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

A single efficient sentence with the key action front-loaded and the id-source clarification in parentheses. No wasted text, though the parenthetical is slightly dense.

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 two-parameter read tool with no output schema, the description covers the primary id parameter and return scope, but omits any explanation of `dossier` and any behavioral detail. It is adequate but leaves clear gaps.

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 0%, so the description must compensate. It meaningfully explains facture_id (the id from the invoice list), but leaves the optional `dossier` parameter completely unexplained in both schema and description, leaving half the parameters ambiguous.

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 (get the detail) and resource (facture/invoice), and adds scope (lignes comprises – line items included). It distinguishes itself from the sibling `factures` list by stating it works 'par son numéro' using the id returned by that list.

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 implies when to use it by telling the agent to obtain the id from the invoice list, effectively routing from `factures` to this tool. However, it gives no explicit when-not conditions or prerequisites (e.g. does the invoice need to exist, any account scoping).

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Liste' implies a read-only operation, but the description says nothing about pagination behavior despite a 'limit' parameter defaulting to 50, nor about ordering, result size, or permissions - significant gaps for a tool with zero annotation coverage.

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

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

A single well-formed sentence with the listing purpose front-loaded and filters in a trailing clause; there is no wasted verbiage. The parenthetical clarifications 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?

With six parameters, no annotations, no output schema, and 0% schema coverage, the description covers the core operation and several filters but leaves 'dossier' and 'limit' unexplained and gives no sense of the return shape. It is adequate but not complete for a tool of this complexity.

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

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

Schema description coverage is 0%, so the description must compensate, and it partially does: it clarifies that chantier_id is the site number within the account and that debut/fin use AAAA-MM-JJ format and are inclusive. However, it omits any explanation of 'dossier' and 'limit', leaving two of six parameters undocumented anywhere.

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 ('Liste les factures émises') and scopes it to issued invoices, so an agent immediately knows this retrieves a collection. However, it does not differentiate from close siblings such as 'facture' (singular) or 'factures_impayees', leaving the agent to infer the boundary.

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

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

It indicates that filtering by statut, chantier, or emission period is possible, which implies the usage context. But there is no explicit when-to-use guidance and no mention of the alternative tools (facture for a single record, factures_impayees for unpaid ones), so the routing decision is left 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?

With no annotations, the description carries the full burden. 'Liste' implies a read-only operation and the parenthetical discloses the filter criteria, which is useful. However, it says nothing about whether the optional dossier filter defaults to all dossiers, whether results are paginated, or the auth scope.

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

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

One compact sentence, front-loaded with the action and resource, with the parenthetical doing real clarifying work. No filler.

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

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

For a simple read-only list with no output schema and no annotations, the description covers what is listed but leaves the dossier filter semantics and result scope unexplained. Adequate but with a clear gap around the only parameter.

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 'dossier' parameter has 0% schema description coverage, and the description never mentions it. An agent cannot tell from either source whether omitting it lists all dossiers or which dossier's unpaid invoices are returned.

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 ('Liste') and a precisely scoped resource ('factures impayées'), then defines the scope with the statuses it includes (envoyées, partiellement payées, en retard). This makes it clearly distinct from the sibling 'factures' (all invoices), though it never names that sibling 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?

No guidance on when to choose this over 'factures', 'facture', or 'marquer_facture_payee'. The parenthetical clarifies what 'impayées' means but offers no usage context, prerequisites, or alternatives.

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

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

With no annotations, the description carries the full burden; it does add two useful facts — a permission requirement and the one-entry-per-expense output granularity. It still omits response format, pagination, and any failure behavior, which matters for an unannotated tool.

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

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

A single compact sentence; period, date format, granularity, and permission each earn their place, and the core resource is front-loaded.

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

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

Without annotations or an output schema, the description should fill more gaps. It covers permission and granularity but says nothing about the undocumented 'dossier' parameter or the shape of returned entries, leaving an agent partially equipped.

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 0%, so the description must compensate. It supplies the date format (AAAA-MM-JJ) for the required debut/fin parameters, adding real meaning, but leaves the optional 'dossier' parameter entirely unexplained in both schema and description.

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 (purchase journal) with the scope (over a period) and granularity (one entry per expense). It is clearly distinguishable from the sales-journal siblings by name, though it never names an alternative explicitly.

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

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

It indicates the required input (a period) and the accounting permission prerequisite, which implies when it applies. However, it never explains when to choose this over journal_achats_csv or journal_ventes, so routing stays inferential.

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

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

With no annotations, the description carries the full burden, and it does disclose useful behavioral facts: CSV output, semicolon separator, comma decimals, and a required accounting permission. It still omits whether this is a read-only export, any row/volume behavior, and date-range handling.

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?

Two terse fragments with zero filler, and the format and permission details are front-loaded. It is arguably under-specified rather than bloated, but every phrase is load-bearing.

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 3-parameter export tool with no output schema and 0% schema coverage, the description covers output format and permission but leaves all parameter semantics and the read-only nature undocumented. It is not complete enough for an agent to construct a correct call unaided.

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 0% and the description adds nothing about the three parameters. It never explains the expected format for debit/fin (the two required dates) or what dossier selects, so an agent must guess the date syntax and the meaning of dossier.

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 resource (purchases journal) plus the output format (CSV), which implicitly distinguishes it from the sibling journal_achats (the non-CSV variant). The verb is absent, but for an export-style tool the noun phrase is clear enough to identify what it 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?

No guidance on when to choose this over journal_achats or journal_ventes_csv. The only usage-relevant hint is 'Permission comptabilité', which signals a prerequisite but not the selection conditions or alternatives.

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

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

With no annotations, the description carries the full burden. It does disclose two valuable traits: the required accounting permission and the fact that the output contains one entry per invoice and credit note. It does not confirm read-only behavior, pagination, or volume limits, which is a notable gap for a report 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?

A single compact sentence that front-loads the resource and scope, then adds granularity and the permission prerequisite. No filler, though the sentence could have been split for easier scanning of the permission requirement.

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 three-parameter reporting tool with no output schema and no annotations, the description covers the essentials of scope, date format, output granularity, and auth. It leaves the optional dossier parameter and the distinction from the CSV sibling unaddressed, so it is adequate but not 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 0%, so the description must compensate. It supplies the date format (AAAA-MM-JJ) for debut and fin, covering two of three parameters, but the optional 'dossier' parameter is undocumented in both the schema and the description, leaving its meaning and effect unexplained.

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 resource (Journal des ventes) with an explicit scope (une période) and output granularity (une écriture par facture et avoir), which clearly distinguishes it from a generic report tool. It does not, however, mention the closest sibling journal_ventes_csv, so the agent must infer the difference between the two.

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?

Usage is implied by the period scope and the stated prerequisite 'Nécessite la permission comptabilité', which is genuinely useful gating information. There is no explicit statement of when to prefer this over journal_ventes_csv or journal_achats, and no exclusions, so guidance remains inferential.

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 two real traits: the required accounting permission and the output formatting conventions. However it says nothing about date-range scoping, defaults, pagination, or what 'dossier' controls, leaving meaningful gaps for an unannotated tool.

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

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

Two compact clauses with no padding; the format specifics are front-loaded and the permission note is appended efficiently. Nothing is wasted, though it is terse rather than maximally informative.

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 3-parameter export tool with no annotations, no output schema, and 0% schema description coverage, the description is too thin: parameters, defaults, and error/precondition behavior beyond the permission note are all 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 0% and the description never addresses 'debut', 'fin', or 'dossier'. An agent must guess that debut/fin are a date range and that dossier selects a file/entity. The format details given are output traits, not parameter semantics, so the 0%-coverage gap is largely uncompensated.

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

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

The description states a specific verb+resource (exports the sales journal as CSV) and pins down the exact format conventions (semicolon separator, decimal comma, French accounting-software import). This distinguishes it from the sibling journal_ventes, though the differentiation is implied by format rather than stated outright.

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 implies the usage context ('tel que l'importe un logiciel de compta français') and states a prerequisite ('Permission comptabilité'), which is useful. But it never explicitly says when to prefer this over the plain journal_ventes sibling, leaving the choice to inference.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the return encoding ('en base64 avec son type'), which is real behavioral value for a download tool. However it says nothing about permissions, authentication, size limits, or error behavior, leaving meaningful gaps for a tool with zero annotation coverage.

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

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

A single well-structured sentence with the action verb front-loaded and the parameter clarifications parenthesized. No wasted text. Slightly dense but appropriately sized for 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?

There is no output schema, so the description is right to state the return format (base64 + type). For a download tool with no annotations, it still omits the `dossier` parameter's purpose and any access/error context, so it is adequate but not 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 0%, so the description must compensate. It clearly explains depense_id ('numéro de la dépense dans le compte') and justificatif_id (the id field from justificatifs_depense), which is genuinely helpful. But the optional `dossier` parameter is never mentioned, leaving one of three parameters undocumented in both schema and description.

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: 'Télécharge un justificatif d'une dépense' (downloads an expense receipt). This distinguishes it from the list-style sibling justificatifs_depense and from pdf_facture. It does not, however, explicitly name the sibling it differs from, 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?

There is no explicit when-to-use/when-not guidance, but the parameter gloss ('justificatif_id = le champ id de justificatifs_depense') implies the workflow: call justificatifs_depense first, then fetch the file here. Usage is inferable rather than stated, so a 3.

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. 'Liste' makes the read-only nature clear and it usefully discloses the nature of the returned items (ticket photos, PDFs) and their fields. It says nothing about permissions, pagination, or what happens when an expense has no receipts, which leaves real gaps for an unannotated tool.

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

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

A single front-loaded sentence that opens with the verb and resource, then qualifies scope and outputs. No filler, though the dense clause structure leaves the 'dossier' parameter unaddressed.

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 two-parameter read tool with no output schema, the description compensates somewhat by naming the returned fields. However it omits any explanation of 'dossier', gives no hint of result shape or emptiness handling, and does not route the agent away from the near-identical 'justificatif' sibling.

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 0%, so the description must compensate. It explains depense_id ('son numéro dans le compte') but the optional 'dossier' parameter is never mentioned in either schema or description, leaving one of two parameters semantically opaque.

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 (Liste) and resource (justificatifs) scoped to a single dépense identified by its account number, and enumerates the returned fields (id, nom, type, taille). It does not, however, explicitly distinguish itself from the very close sibling 'justificatif' (singular), leaving the list-vs-single distinction to inference.

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 never says when to use this tool versus the sibling 'justificatif', 'depenses', or 'pdf_facture'. The phrase 'par son numéro dans le compte' only implies that an expense id is needed; there is no explicit when/when-not guidance.

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

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

No annotations are provided, so the description carries the full burden and does reasonably well: it discloses the auth/permission requirement (invoices + expenses scope) and the exact computation semantics (billed revenue minus site expenses). It does not describe the response shape or how the value is returned, which is the remaining gap.

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

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

Three compact sentences with the deprecation/alternative notice front-loaded, followed by definition and prerequisites. Every sentence earns its place; no filler or repetition.

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, the description does most of the load-bearing work: it explains what is computed, so the return value is inferable, and it states required permissions. The unexplained `dossier` parameter is the one meaningful omission.

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 0%, so the description must compensate. It partially clarifies `chantier_id` ('par son numéro dans le compte' — the account's site number), but the optional `dossier` parameter is never mentioned anywhere, leaving half the input surface undocumented in both schema and prose.

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 resource (chantier margin) and defines it precisely: billed revenue minus expenses attributed to that site. It also marks itself as a deprecated compatibility shim and points to `marge_client`, so an agent can distinguish it from the near-identical sibling without opening either schema.

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

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

It gives explicit routing guidance: 'préférer `marge_client`' for new work, and states this tool is kept only for backward compatibility. It also names the required key permissions (factures + dépenses), which is an actionable prerequisite for invocation.

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 well: it discloses the required permissions (factures + dépenses), the output breakdown including the special `sans_document` line, and a conditional behavior (`depenses_en_ttc` true for VAT-exempt accounts). It does not cover pagination or precise return format, but for a read-only computation that is a minor 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 purpose and scope are front-loaded, and the paragraph is dense but each sentence conveys distinct information (breakdown, equivalence, VAT flag, permissions). Slightly heavy, but nothing is clearly wasted.

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

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

For a two-parameter computation tool with no annotations and no output schema, the description is complete enough: it explains the input identity, the computed output structure, the special-case line, and the permission prerequisite. Only the `dossier` parameter is left unexplained, which is a small residual gap against an otherwise rich description.

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 0%, so the description must compensate. It does explain `client_id` well by tying it to the `id` field of the clients tool, but it says nothing about the `dossier` parameter (default null), leaving one of two parameters entirely undocumented in both schema and description.

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 computed resource (a client's margin), specifies the exact input identity (`client_id` = the client number, i.e. the `id` field from the clients tool), and enumerates the breakdown structure (total, per job, plus a `sans_document` line). This lets an agent distinguish it from `marge_chantier`, whose scope is sites rather than clients, without opening either schema.

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

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

It gives useful context ('mêmes chiffres que la fiche client de VoxFactura', needs a key with factures + dépenses permissions), which implies when the tool is appropriate. However, it never explicitly names an alternative or an exclusion (e.g. use `marge_chantier` for per-site margin), so the routing decision must be inferred.

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

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

With no annotations, the description carries the full burden. It usefully discloses the required permission (payments:write) and the partial-vs-full payment semantics, but says nothing about reversibility, side effects, or what the operation returns.

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

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

A tight, front-loaded paragraph with no filler: action, permission, then per-parameter clarification. Every clause carries information.

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

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

For a mutation tool with no annotations and no output schema, the definition covers the permission and the two most important parameters but omits any account-scoping explanation for `dossier` and any statement of effect or return. Adequate but with clear gaps.

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 0%, so the description must compensate and it partly does: it defines facture_id as the invoice number within the account and explains montant's text format (e.g. « 500.00 ») and its partial-payment meaning. The `dossier` parameter is left completely undocumented, leaving a real gap.

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

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

The description opens with a specific verb+resource action ('Marque une facture payée'), which is immediately distinguishable from read-oriented siblings like factures/encaissements. It does not explicitly contrast itself with siblings such as factures_impayees, but the mutation intent 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?

There is an implicit usage condition baked into the parameters: a non-empty montant means a partial payment, an empty one settles the full balance. However, no when-to-use-vs-alternatives guidance or prerequisites beyond the permission string is offered, leaving the agent to infer the routing.

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

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

No annotations are provided, so the description carries the burden. It adds one genuinely useful behavioral fact — that the `devis:write` permission is required — but never states whether this is a read-only listing, how many results to expect, or whether the templates are user-scoped. The write-permission disclosure is worth credit but leaves the operation's nature ambiguous.

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

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

A single compact sentence that front-loads the resource and the permission constraint. Nothing is wasted, though the parenthetical permission sits awkwardly mid-sentence.

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

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

For a one-optional-parameter listing tool this covers the resource, its fields, and the permission, and the absence of an output schema is mitigated by the enumerated fields. The undocumented `dossier` parameter is the notable gap.

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

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

Schema coverage is 0% and the single parameter `dossier` is never mentioned in the description. An agent cannot tell whether it filters templates by a specific job/folder or what happens when it is omitted (the schema only shows default null).

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 resource (quote templates for the tradesperson) and enumerates the fields each template carries (numéro, nom, objet, variables), and explicitly links it to the sibling `devis_depuis_modele`. It is clear this is the catalogue that feeds that tool, though the verb (list/retrieve) is only implied.

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?

By saying the variables are 'to fill in for devis_depuis_modele', it implies you consult this tool before calling the template-filling tool. It does not state exclusions, prerequisites beyond the permission, or what to do if no templates exist.

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

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

With no annotations, the description carries the full burden. It does disclose the return shape (base64 payload plus filename) and a precondition (drafts have no PDF), which is real behavioral value. It omits any mention of permissions, error behavior, or size/latency considerations.

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?

Two compact sentences with zero waste; the resource and return format are front-loaded, and the draft caveat follows efficiently.

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

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

For a PDF-retrieval tool with no output schema and no annotations, the description covers the return format and the draft limitation, but leaves the 'dossier' parameter and any failure modes unexplained, so it is only minimally 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 0%, so the description must compensate. It clarifies facture_id as 'son numéro dans le compte' (the invoice number within the account), but the 'dossier' parameter is never mentioned, leaving half the parameters undocumented in both schema and description.

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

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

States a specific verb and resource: retrieving the Factur-X PDF of an issued invoice, returned as base64 with its filename. This distinguishes it from sibling read tools like facture/factures, though it doesn't explicitly name those alternatives.

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 clause 'Un brouillon n'a pas de PDF' gives an implicit when-not condition (drafts cannot be retrieved), which is genuinely useful. However, it offers no explicit guidance on when to prefer this over the sibling 'facture' tool, leaving usage largely inferred.

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 must carry behavioral disclosure; it does state the required accounting permission and the output summary fields, which adds value. However, it does not say whether the operation is read-only, whether it has side effects, or any rate/limit behavior, leaving significant gaps.

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?

Two compact sentences with no filler; the core function is front-loaded immediately.

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 three parameters, no annotations, no output schema, and zero schema descriptions, the description is incomplete: it omits parameter details, usage alternatives, and return structure beyond naming the three VAT amounts.

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 0%, so the description must explain the three parameters. It only supplies the date format for the period and never mentions the optional dossier parameter or why debut/fin are required, leaving most parameter semantics undocumented.

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écapitulatif TVA sur une période' and lists the three computed amounts (collectée, déductible, TVA nette). It does not explicitly distinguish this recap from sibling journal or expense tools, so it falls short of 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 only usage context is the prerequisite 'Nécessite la permission comptabilité' and the date format. There is no guidance on when to choose this recap versus journal_ventes, journal_achats, or other sibling tools, nor any exclusions.

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