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 that expenses:write permission is required and that amounts are passed as text (e.g. '240.00'), which is non-obvious behavior. But it does not disclose what a created expense returns, idempotency/duplicate handling, or error behavior for a write 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?

Three short, front-loaded sentences with the action stated first and no filler. Efficient, though it leans on terse parentheticals rather than a fully structured statement.

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 mutation tool with no annotations, no output schema, and 0% schema coverage, the description is thin: it omits return behavior and most parameter meanings, so an agent lacks what it needs to call this confidently.

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 only explains montant_ttc's text format and chantier_id's meaning (worksite number in the account), leaving categorie, fournisseur, montant_ht, montant_tva and designation undefined—most of the 7 parameters are 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 ('Ajoute une dépense'), so an agent can tell it apart from the read-oriented sibling 'depenses'. However it never explicitly contrasts itself with that sibling, so the differentiation is implied 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 gives no when-to-use or when-not-to-use guidance and names no alternative among the many siblings (depenses, journal_achats, factures). The only implicit signal is the required permission expenses:write, which is a prerequisite, not usage 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 full behavioral burden. It conveys that this is a read/lookup operation, but discloses nothing about permissions, error behavior (unknown id), or response shape.

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 purpose, with the parenthetical clarifying parameter origin. No wasted text.

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

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

For a single-parameter lookup with no output schema, the definition covers input semantics but says nothing about what the detail response contains. Adequate but not complete given the missing output schema.

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

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

Schema coverage is 0% and the schema only names the type, but the description meaningfully explains that `chantier_id` is the `id` field returned by the chantiers list, adding real semantics beyond the bare integer 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?

States a specific verb+resource ("Détail d'un chantier") and scopes it to a single record by number. It implicitly distinguishes itself from the plural sibling `chantiers` by pointing to that list as the source of the id.

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 implies usage (fetch a detail by id obtained from the list) but does not state explicit when-to-use/when-not conditions or alternatives such as `marge_chantier`. Guidance is inferred rather than declared.

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 operation, but nothing is said about result size, ordering, pagination, or whether all chantiers are returned by default when no filter is supplied — significant gaps for a list endpoint 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 front-loaded sentence stating the action before the filter conditions; no filler. The two filters are packed into one trailing parenthetical, which is dense but still readable.

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

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

With no output schema and no annotations, the description should say more about what comes back and how results are bounded; it says nothing about return shape, ordering, or limits. The parameter gap is partly covered, but the behavioral/return gap is not.

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% — the properties are bare 'string'/'integer' with only titles — so the description must compensate, and it does: it enumerates example status values ('en_cours, termine…') and defines client_id as the client number within the account. It stops short of listing all valid statuses or their allowed set.

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 ('Liste les chantiers') and the two optional filter dimensions, so the operation is unambiguous. However, it never differentiates itself from the sibling 'chantier' (singular) or 'marge_chantier', leaving the agent to infer that this is the collection-level list versus a detail view.

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 'éventuellement filtrés par statut... ou par client' implies when the filters apply, so usage is implied rather than stated. There is no explicit guidance on when to prefer this tool over 'chantier' or 'clients', nor any exclusion or prerequisite.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Liste' implies a read-only operation, it does not mention output format, pagination, sorting, or any side effects. For a complete picture, more detail is needed.

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, concise French sentence that is front-loaded with the action verb. Every word earns its place, with no redundant or extraneous 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 simple list tool with one optional parameter and no output schema, the description is minimally adequate. It states the purpose and parameter, but lacks details about the response format or any limits. It is not misleading, but could be 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 description explicitly explains the 'recherche' parameter as an optional text search, adding meaning beyond the raw schema which only shows a nullable string. This is sufficient for a single simple parameter, though it does not detail which fields are searched.

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 lists clients and supports an optional text search. The verb 'Liste' is specific and the resource 'clients' is unambiguous, distinguishing it from sibling tools that deal with invoices, expenses, and projects.

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 is provided on when to use this tool versus alternatives or any exclusions. The description simply states what it does, leaving the agent to infer usage context without explicit direction.

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 so well. It discloses the required write permission, draft-only status, non-automatic sending, numbering behavior ('numero' null until sent), and default inheritance for optional fields.

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

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

The description is front-loaded with the core action and every sentence adds substantive detail about defaults, line structure, or lifecycle. It is slightly long, but the density is justified by the creation complexity.

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 create tool with no annotations or output schema, it supplies key defaults, permission requirements, and draft/numbering semantics. It is not fully complete because 'notes' and 'objet' are never explained and no return shape is described.

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 documents client_id, chantier_id, the nested 'lignes' item fields, validite_jours defaults, and delai_execution, but it leaves 'notes' and 'objet' completely 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 opens with a specific verb and resource: 'Crée un devis en BROUILLON'. It also states the required permission (devis:write), making the action unambiguous and distinguishable from facture-oriented 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?

It implies when to use the tool by describing the draft workflow and that the quote is never sent automatically, but it does not explicitly contrast this with alternatives or provide clear when-not-to-use conditions.

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. 'Liste' implies a read operation, but it does not state whether results are paginated, how many records return by default, whether auth/permissions are required, or what happens when no filter is supplied (all expenses vs none).

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 verb first and filter options trailing; no wasted words. Slightly tight to the point of under-explaining, but structurally clean.

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/list tool with two optional filters and no output schema, the core purpose and filters are covered. Missing behavioral context (default scope, return shape, pagination) leaves the agent guessing about what a call with no arguments actually yields.

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 explains that chantier_id is the 'numéro du chantier dans le compte' and that filter is by category. That adds real meaning beyond the bare schema, but 'categorie' gets no more than its plain-language equivalent and no accepted value format is given.

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') and clarifies the domain term ('factures de frais'). However, it never names the sibling that distinguishes it, notably 'ajouter_depense' (add expense), so an agent must infer the read-vs-write split from the verbs alone.

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

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

The description mentions that results are filterable by chantier or catégorie, which hints at usage, but gives no explicit when-to-use or when-not-to-use guidance relative to alternatives like journal_achats, factures, or ajouter_depense. Nothing tells the agent when this tool is the right choice.

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 output format (tab-separated text), and the required accounting permission, but says nothing about how the file is delivered, whether the operation is read-only, or any size/period limits.

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

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

Two compact lines, front-loaded with the resource and format, then the audience and prerequisite. Nothing is padded, though the phrasing could be slightly tighter.

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 export with no output schema, the description covers what is produced and the permission requirement, but omits how the result is returned and what the year value must be, leaving gaps an agent would need to guess at.

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 parameter 'annee' has 0% schema description coverage. The description only refers to 'l'année', which merely restates the parameter name and adds no format, calendar-vs-fiscal-year, or range guidance, so it fails to compensate for the coverage 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 gives a specific verb and resource: exporting the FEC (Fichier des écritures comptables) as a tab-separated text file for the year, and adds the intended recipient (the accountant). It is clearly distinct from narrower siblings like journal_ventes or journal_achats, though it does not explicitly name them.

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

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

It states the purpose ('à remettre à l'expert-comptable') and the prerequisite permission, which implies when to use it, but never contrasts it with the related export/report siblings (journal_ventes, journal_achats, recap_tva) or says when not to use it.

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

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

With no annotations, the description carries the full behavioral burden. 'Détail' implies a read operation and 'lignes comprises' tells the agent line items are included, but there is no statement of permissions, behavior for an unknown id, or account scoping beyond the vague phrase 'dans le compte'.

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 tight sentence, front-loaded with the action and scope, with the parameter provenance placed in a parenthetical. Every clause earns its place; only the nested parentheses slightly reduce 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 a single-parameter read tool with no annotations and no output schema, the description covers purpose, the meaning and origin of the id, and what the response contains (invoice lines). What is missing — error behavior and auth expectations — is modest for a simple lookup.

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 does: it explains that the parameter is the invoice number taken from the `id` field returned by the invoice list, which is far more useful than the bare `Facture Id` integer field. It stops short of restating the type or format constraints.

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 action ('Détail d'une facture'), the resource, and the scope ('lignes comprises'), and explicitly distinguishes itself from the list tool by stating the id comes from 'la liste des factures' (sibling `factures`). An agent can tell at a glance that this fetches one invoice in full rather than listing them.

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

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

Usage is implied: call this after obtaining an id from the invoice list to inspect a single invoice. There is no explicit when-not guidance and no exclusions (e.g., versus `factures_impayees` or `marquer_facture_payee`), so the routing is left to inference.

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

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

With no annotations, the description carries full behavioral burden, yet it only restates purpose. It doesn't mention pagination behavior, the 'limit' default, or the shape of returned data, all of which matter 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?

A single front-loaded sentence with the core purpose first and filters second; every clause adds information. It is efficient, though a bit terse given the coverage gaps.

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 or annotations exist, so the description should do more. It covers purpose and two filters but omits pagination/'limit' semantics and return structure, leaving gaps for an agent invoking it.

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

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

Schema coverage is 0%, so the description must compensate, and it does partially: it clarifies 'chantier_id' means the site number within the account and that 'statut' filters by status. The 'limit' parameter and valid 'statut' values remain 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 factures émises'), and adds scope via the optional filter mention. It's clearly distinguishable from the singular sibling 'facture', but it doesn't explicitly name alternatives like 'factures_impayees'.

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 'éventuellement filtrées par statut ou chantier' implies how the filters are used, giving modest usage context. It never states when to prefer this tool over siblings such as 'facture' or 'factures_impayees', and offers no 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. 'Liste' implies a read-only query, but it does not explicitly state the absence of side effects, authentication requirements, or return format. The parenthetical statuses add useful context but do not disclose behavioral traits beyond the 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?

The description is a single sentence that is front-loaded with the action and resource. It is concise with no unnecessary words, earning its place entirely.

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 parameters and no output schema, the description is mostly complete. It clearly identifies what is returned (unpaid invoices with specified statuses). Missing is an explicit statement about being read-only or any confirmation of the output nature, but the simplicity of the tool reduces the burden.

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

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

The tool has no parameters, and the schema is empty with 100% coverage vacuously. Since there are no parameters to explain, the baseline of 4 applies. The description adds no parameter information, which is acceptable given the absence of parameters.

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

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

The description uses a specific verb 'Liste' (lists) and a specific resource 'factures impayées' (unpaid invoices), clearly distinguishing it from sibling tools like 'factures' (all invoices) and 'facture' (single invoice). The parenthetical statuses further clarify the scope.

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

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

The description states what the tool does but provides no guidance on when to use it versus alternatives like 'factures' or 'marquer_facture_payee'. There is no mention of scenarios or exclusions, so the agent must infer usage from the tool name alone.

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 real behavioral trait (the accounting permission prerequisite) and the output granularity (une écriture par dépense), plus the date format. It does not state that it is a read-only operation, nor anything about ordering, pagination, or behavior on empty periods.

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 sentence that front-loads the resource and period, followed by two compact qualifiers. No filler, though the parenthetical date format slightly interrupts the main clause.

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 or annotations, the essentials are present: scope, date format, permission requirement, and row granularity. Missing details about return contents (totals? ordering? empty results?) keep it at minimum-viable rather than complete.

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

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

Schema coverage is 0% and both parameters (debut, fin) are undocumented in the schema, so the description must compensate. It supplies the date format (AAAA-MM-JJ), which is genuinely useful, but does not clarify range inclusivity or whether fin is exclusive, leaving residual ambiguity.

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

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

Names a specific resource (journal des achats) and scope (sur une période), so an agent can immediately distinguish it from journal_ventes and export_fec, which appear in the sibling list. It stops short of explicitly contrasting itself with those siblings, so it is clear but not fully differentiated.

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?

Provides context that it is a period-bounded report and that it requires the comptabilité permission, which lets an agent decide feasibility. However, it never states when to prefer this over journal_ventes, export_fec, or depenses, so routing is left to inference.

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

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

With no annotations, the description carries the full burden. It does disclose two useful traits beyond the name: the accounting permission requirement and the one-entry-per-invoice-and-credit-note output granularity. However, it says nothing about pagination, ordering, volume limits, or return format for a period report.

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 packs purpose, date format, entry granularity, and the permission prerequisite with no redundant filler. Efficient, though the parenthetical date format interrupts the purpose statement 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 two-parameter read report with no output schema and no annotations, the description covers the essentials: what it returns, the required date format, and the auth requirement. Output structure is only summarized, but that is adequate at 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. It supplies the critical missing semantic — the date format (AAAA-MM-JJ) — and clarifies that the two parameters bound a period, which the schema alone (bare 'Debut'/'Fin' titles) does not convey.

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

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

States a specific resource (journal des ventes) with scope (sur une période) and defines the granularity: one entry per invoice and credit note. An agent can infer it differs from journal_achats, but the sibling is never named explicitly, so differentiation is left 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?

There is no explicit when-to-use guidance or statement of when a different tool (e.g. journal_achats, export_fec, recap_tva) would be preferred. The accounting-permission prerequisite is mentioned, but that is a precondition rather than selection 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 behavioral burden. It discloses the calculation formula and required API permissions, which is useful context, but omits whether the operation is read-only, the time period covered, and error 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?

Two tightly written sentences with no filler. The purpose, formula, and prerequisite permission are front-loaded and 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?

For a simple calculation tool with no output schema, the description covers the formula and permission requirement. However, it omits the time period for revenue and expenses and the return format, which are important for correct interpretation of the margin.

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% with one parameter. The description adds meaning by saying the chantier is identified 'par son numéro dans le compte', partially compensating for the lack of schema detail, but does not clarify format, range, or whether it matches the internal integer ID.

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 clearly that it computes the margin for a construction site, defined as billed revenue minus expenses. The resource and calculation are specific, though it does not explicitly differentiate itself from sibling tools like chantier or depenses.

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?

Provides only a permission prerequisite ('Nécessite une clé avec les permissions factures + dépenses') but no guidance on when to use this tool versus alternatives like chantier or factures. The agent must infer usage from the name and purpose alone.

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 required permission (payments:write) and the behavioral distinction between a partial payment and an empty montant settling the total balance. It omits reversibility, effects on existing payments, and error 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?

Three compact sentences with zero waste; the action and its permission, then each parameter's meaning, are front-loaded and easy to parse.

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 mutation with no output schema and no annotations, the description covers the permission requirement, both parameters' meanings, and the partial/total settlement behavior. It is nearly complete, leaving only edge-case behavior (reversibility, overpayment) unstated.

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

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

Schema description coverage is 0%, so the description must compensate and it does: facture_id is 'numéro de la facture dans le compte' and montant is described as text with a concrete example ('500.00') and the semantic that empty settles the total. Minor gap: no format constraints or bounds on montant beyond the example.

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: 'Marque une facture payée' clearly identifies the mutation (mark an invoice as paid) on the facture resource. It is distinct from the read-oriented siblings (factures, facture, factures_impayees) but does not explicitly contrast with them.

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

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

Usage is implied by the tool name and the partial-vs-full payment nuance ('paiement partiel ; vide = solde le total'), which tells the agent when to send a montant. However, there is no explicit when-to-use vs alternative guidance or mention of prerequisites beyond the permission string.

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 of disclosing behavior. It mentions the required accounting permission, the date format (AAAA-MM-JJ), and the returned fields. It does not explicitly state that the operation is read-only, but the word 'summary' implies it, and the permission note adds important context.

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

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

The description is a single, front-loaded sentence containing all key information: purpose, date format, outputs, and permission. No unnecessary words 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?

For a simple summary tool, the description covers the essential aspects: what it does, the inputs' format, required permission, and the output fields. Without an output schema, this is sufficient for an agent to understand the tool's functionality, though it could optionally state whether the summary is global or filtered.

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 descriptions, so the description compensates by indicating the parameters define a period and specifying the date format. However, it does not explicitly map debut and fin to start and end dates, leaving some inference to the agent.

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 produces a VAT summary for a date range, listing the specific computed values (collected, deductible, net VAT). This distinguishes it from sibling tools like factures or depenses by focusing on aggregated VAT reporting.

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 intended use is implied by the description: obtain a VAT summary for a period. However, it does not explicitly mention when to use this tool instead of alternatives or any exclusions, such as if a per-client breakdown is needed.

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