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

Annotations already declare readOnly, idempotent and closed-world, so this is a safe simulation call. The description adds that the estimate is derived from the average gross monthly salary and that it returns both amounts and duration, which is useful. It does not disclose the regime assumptions (e.g. the 1 September 2026 rupture conventionnelle rules, or the 24/36-month reference period) that materially change results.

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 that front-loads the action and enumerates the outputs in one clause. No filler or restatement of the title.

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 five-parameter simulation with no output schema, the description conveys the returned quantities but not their form (units, whether net of contributions, whether duration is given in days or months) and glosses over the conditional age and contract-break logic. Adequate to call, thin on interpretation.

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 80% and descriptions there already define salaireBrutMensuelMoyen, moisTravailles, ageMoins55 and ruptureConventionnelle, so the baseline is 3. The description adds nothing beyond the schema, and trancheAge (an enum) is undocumented and its relationship to ageMoins55 unexplained, leaving the ambiguity unaddressed.

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

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

Specific verb (estime) plus resource (allocation chômage ARE) plus the three outputs produced (montant journalier, mensuel, durée d'indemnisation) and the input basis (salaire brut mensuel moyen). It is clearly distinct from indemnite_licenciement or rupture_conventionnelle, though it never names the closest sibling to differentiate further.

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 statement of when to use this tool rather than alternatives such as solde_tout_compte, which also touches unemployment context, nor any prerequisite (e.g. reference period, age branch selection). The 'Compatibilité' hint is ambiguous about how ageMoins55 and trancheAge interact. The agent must infer the routing 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?

Annotations already declare readOnly, idempotent and closed-world, so safety is covered. The description adds that both tax regimes and ACRE are handled, which is genuine behavioral context. However, it says nothing about which parameters take precedence (caMensuel vs caAnnuel), the assumed 2026 parameter set, or whether missing inputs are defaulted — relevant for a pure calculator.

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 naming the outputs first and the special case (ACRE) last, with no filler. It is efficient, though thin enough that brevity shades into under-specification for an 8-parameter tool.

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

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

For a deterministic calculator with no output schema, the description does name the three return values (cotisations, impôt, revenu net) and the ACRE dimension. What is missing is input precedence and defaulting behavior, which matters given 8 parameters at 50% schema coverage.

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 8 parameters and only 50% schema description coverage, the description carries real compensating burden but adds little. It only hints at ACRE and the two tax modes (mapping loosely to acre/beneficiaireAcre and versementLiberatoire); caMensuel vs caAnnuel precedence, tauxPrelevementSource use, and default behavior remain undocumented in both places.

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

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

States a specific verb set (calcule) and precise resources: cotisations URSSAF, impôt (versement libératoire ou barème), revenu net, plus ACRE. This clearly separates it from siblings like seuils_micro_entreprise (thresholds only) or freelance_tjm_ca_net (TJM-based), though it never names any 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?

Usage is implied by the domain: the agent can infer it should be used for a micro-entrepreneur income simulation. There is no explicit when-to-use, when-not-to-use, or routing to alternatives such as comparatif_statuts or seuils_micro_entreprise, so the agent must infer boundaries from the 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds what each mode computes, but says nothing about the assumptions behind the numbers (tax brackets, year, cotisation rates), whether results are estimates, or how the comparison is presented. That is a meaningful gap for a calculation 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 tight sentences with no filler; the comparison scope comes first and the mode semantics second. The mode clause is slightly repetitive relative to the revenuMensuelSouhaite schema text, but it is not 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?

There is no output schema, so the description should say something about the result (a comparative table of net figures per status, in what units). It covers inputs and the two mode semantics but leaves the return shape and underlying fiscal assumptions undocumented — 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 67% and the two documented parameters already match the description's wording, but the description supplies the crucial meaning of the "mode" enum, which the schema lists with no description at all. It does not add anything about chargesMensuelles beyond the schema, which is the residual 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?

States a specific verb ("Compare") and enumerates the exact statuses covered (salarié, micro-entreprise, portage, SASU salaire/dividendes, EURL à l'IR), so the scope is unambiguous. It implicitly distinguishes itself from the single-status siblings (auto_entrepreneur, portage_salarial, freelance_tjm_ca_net) by being the cross-status comparison, but never names 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?

The two modes ("ca" and "net") frame the two use cases, which implies when to reach for each, but there is no explicit guidance on when to prefer this tool over the individual-status siblings or what prerequisites (e.g. regime assumptions) apply. Usage is inferred rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing the computed dimensions and that a recommendation ('la meilleure') is returned, but it is silent on key behavioral assumptions such as which tax/contribution model is applied, how missing primes or RTT are treated, and whether the verdict is a single field or a breakdown.

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 states the operation, the inputs it considers, and the output. No filler or redundancy.

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

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

For a tool with two nested-object parameters, a required enum, 0% schema coverage and no output schema, the description is too thin: it omits statut entirely, does not explain units or optional-field defaults, and only hints at the return value ('indique la meilleure').

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 carry parameter meaning. It maps loosely onto brutMensuel, primesAnnuelle and rttJours, but never mentions the required 'statut' enum (cadre/non-cadre), which drives the net calculation, and gives no units or currency for the numeric fields.

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

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

The description names a specific verb (compare) and resource (two job offers), and lists the comparison dimensions (net monthly, bonuses, RTT value) plus the outcome (identifies the better offer). This separates it from siblings like salaire_brut_en_net or comparatif_statuts, though it never names those alternatives explicitly.

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

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

The usage is implied by 'compare deux offres d'emploi' – an agent can infer this is for choosing between two job offers. However, there is no explicit when-to-use guidance, no mention of when to prefer this over comparatif_statuts or salaire_brut_en_net, and no stated 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?

Annotations already declare readOnly, idempotent and closed-world. The description adds genuine value by disclosing the computation logic (two methods, keep the more favorable), which the annotations cannot convey. However, it says nothing about rounding, output shape, or handling of the optional remunerationReference, leaving the behavioral picture 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?

A single front-loaded sentence that conveys verb, resource and algorithm with zero padding. Efficient, though it could be slightly richer without becoming verbose.

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

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

For a read-only calculator with no output schema, the description states what is computed and that the more favorable of two methods is retained, which is enough to invoke correctly given the very rich parameter schema. The only minor gap is the lack of return-value framing, largely offset by the schema richness.

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

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

Schema description coverage is 100%, with extensive legal context in the decompte parameter, so the schema does the heavy lifting. The description adds no parameter-level detail, which is acceptable at full coverage but means it neither compensates nor improves.

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 ('Calcule l'indemnité de congés payés') and even names the computation method (comparison maintien de salaire vs règle du dixième). This distinguishes it from the sibling conges_payes_jours_acquis, which handles acquisition rather than indemnity, though it doesn't explicitly name that sibling.

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 purpose (computing the indemnity once days are known), but there is no explicit when/when-not guidance and no reference to alternatives such as conges_payes_jours_acquis, which a caller would likely need first to obtain joursAcquisPeriode.

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

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

Annotations already declare readOnly=true, idempotent=true and closed-world, so the safety profile is covered. The description adds genuinely useful scope context (2024 sick-leave rules included in the calculation and the reference period), but says nothing about what is returned or how the calculation handles the optional sick-leave parameter.

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 zero filler: verb, resource, scope condition, and rule version. Nothing is wasted or buried.

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

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

For a 3-parameter read-only calculation with no output schema, the description covers the input-side scope adequately but never indicates what the tool produces (acquired days, remaining days, indemnity). An agent must infer the return shape from the enum text rather than the 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 coverage is 100% and the enum description already carries the full legal ruleset (2.5 days/month, 2 days/month for non-work illness, 30-day cap, indemnity methods). The description only signals that sick leave feeds the calculation. Baseline 3 applies since the schema does the heavy lifting.

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

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

States a specific verb and resource ("Calcule les jours de congés payés acquis") with an explicit scope qualifier ("arrêts maladie compris, règles 2024"). This distinguishes it reasonably from siblings like conges_payes_indemnite and solde_tout_compte, though the distinction 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 implies usage via the period-of-reference and arrêts-maladie scope, but never says when to call this vs. conges_payes_indemnite (which covers the indemnity side) or solde_tout_compte (the full balance). No exclusions or prerequisites are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds nothing about the nature of the result (an estimate under French social-charges rules), the assumed defaults, or which inputs are mutually exclusive — a 3 reflects annotations doing most of the work.

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

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

One front-loaded sentence with no filler; the verb and resource come first and the status list is compact. It is efficient but under-specified rather than over-long.

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

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

For an 11-parameter simulation with no output schema and heavy tax/legal assumptions (charges déductibilité, dividendes, prélèvement à la source), the description does not say what is returned or how to combine required and optional inputs. An agent would have to open the schema and guess at the TJM vs CA exclusivity.

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 only 64% across 11 parameters, and the description contributes zero parameter meaning. Critically, it does not explain that tjm and caMensuel are alternative inputs or what joursParMois defaults to — ambiguities the schema does not resolve either.

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: converts a daily rate (TJM) or monthly revenue into net freelance income, and enumerates the five legal statuses covered. Clear enough to separate it from single-status siblings like auto_entrepreneur or portage_salarial, though it never names those siblings 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 pick this multi-status converter versus comparatif_statuts, auto_entrepreneur, portage_salarial or seuils_micro_entreprise, all of which overlap. The status enumeration hints at the overlap but gives no selection rule 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and a closed world, so safety and repeatability are covered without the description. The description adds that the calculation spans employer/employee contribution reductions and tax exemption, which hints at the output's composition, but it says nothing about required inputs, defaults (0.22 charges, 0.25/0.5 majorations, 35 h), or what the result looks like.

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

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

One dense, front-loaded sentence with zero filler — the verb and the computed outputs come immediately. It is arguably too short for a 12-parameter tool, but nothing in it is wasted.

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

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

For a 12-parameter, no-output-schema calculation tool, the definition leaves the agent guessing which of the two rate inputs to supply, how heuresContratHebdo affects prorating, and how the required overtime hours interact with the optional ones. The annotations are minimal (read-only only), so the description should carry more of this load than it does.

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?

At 58 % schema coverage across 12 parameters, the description only partly compensates. It maps to tauxMajoration1/tauxMajoration2 and reductionSalariale, but the crucial choix entre tauxHoraireBrut et salaireMensuelBrut, plus heuresComp10 (temps partiel) and tauxChargesNet, are left entirely to the schema. Baseline 3 is appropriate given moderate coverage.

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

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

States a specific verb ("Calcule") and a specific resource ("rémunération des heures supplémentaires") and lists the components produced: majorations 25 %/50 %, réduction de cotisations, part exonérée d'impôt. It does not name or distinguish itself from any sibling calculator (salaire_brut_en_net, conges_payes_indemnite), but the payroll-adjacent purpose is unambiguous.

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

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

There is no when-to-use, when-not-to-use, or alternative routing guidance at all. An agent cannot tell from the description whether this should be called alongside salaire_brut_en_net or standalone, nor what prerequisites (hourly rate vs monthly salary) select this tool.

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

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

Annotations already declare readOnlyHint, idempotentHint and closed-world, so the safety profile is clear. The description adds genuinely useful domain context (legal vs. Syntec/Métallurgie conventional formulas, driven by reference salary and seniority). It does not disclose the behavioral effects of `fauteGrave` (which strips the indemnity) or `ruptureConventionnelle`, nor what the result contains.

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

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

A single front-loaded sentence with zero filler; the resource and its scope come first. It is efficient but leaves no room for the routing or parameter guidance the tool needs.

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

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

For an 11-parameter legal-calculation tool with no output schema, the description should at minimum say what the result is and how the salary inputs interact, and clarify the effect of `fauteGrave` and `ruptureConventionnelle`. As written, an agent cannot confidently populate the optional parameters or interpret the answer.

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 only 36% across 11 parameters, so the description must compensate and largely does not. It names the two conceptual inputs (salaire de référence, ancienneté) but leaves `fauteGrave`, `convention`, `tauxCotisations`, `ancienneteMois`, and the net/brut salary fields unexplained, and does not say which salary field takes precedence.

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 ('Calcule l'indemnité légale de licenciement') and even scopes the variants covered (légale, Syntec, Métallurgie). An agent can tell it apart from generic payroll siblings, though it never names or contrasts the nearby `rupture_conventionnelle` 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 by the phrase 'indemnité légale de licenciement' – the agent must infer this is the tool for computing severance on dismissal. There is no explicit when/when-not, no mention of the `rupture_conventionnelle` sibling, and no note that only `ancienneteAnnees` is required while the other ten parameters are optional enrichments.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful fact that results follow the official fiscal barème, but says nothing about the comparison behaviour hinted at by 'autresFraisReels' and 'salairesNetsImposables', nor about the shape of the returned result.

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

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

One tightly written sentence with no filler, and the calculation basis is front-loaded. It is arguably too terse for a six-parameter tool, but every word earns its place.

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

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

With six parameters, 33% schema coverage, no output schema, and clear evidence of a comparison feature (frais réels vs abattement 10%), the description should explain what the tool returns and what 'electrique' does. It stops at naming the barème inputs, leaving the most consequential behaviour undocumented.

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 only 33%, so the description must carry weight; it does explain typeVehicule (voiture/moto/cyclomoteur), puissanceFiscale and distanceAnnuelle. It is silent on 'electrique' (a materially important option for the barème) and on how the two optional comparison parameters affect the output.

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 ('Calcule') and resource ('indemnités kilométriques') and names the calculation basis (barème fiscal, vehicle type, fiscal horsepower, annual distance). No sibling tool covers mileage allowances, so confusion risk is low, but the description never explicitly distinguishes itself from the payroll/simulation 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?

Usage is only implied by the domain vocabulary; there is no statement of when to pick this calculator over a sibling such as salaire_brut_en_net, and no prerequisites or exclusions are given. An agent must infer the context from the name and required parameters 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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safe, deterministic, offline nature is covered. The description adds nothing about what the computed figure represents (net before or after prélèvement à la source, whether frais professionnels are deducted or reimbursed on top), which is the one behavior an agent would actually need here.

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 calculation and its inputs front-loaded; nothing redundant. It is arguably too terse rather than bloated, so the score reflects efficiency rather than ideal coverage.

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?

Six optional parameters, no output schema, and no explanation of how tjm interacts with caMensuel or what the return value contains. For a calculation tool where the output shape is undefined, the description should at least state what is produced; it doesn't.

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 50%; the description names the business concepts behind three parameters (chiffre d'affaires, frais de gestion, frais professionnels), which partially compensates. It says nothing about tjm vs caMensuel (alternatives? derived?) nor about tauxPrelevementSource and joursTravaillesParMois, leaving half the inputs to the schema alone.

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

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

States a concrete verb ('Calcule') and a specific resource ('salaire net en portage salarial'), plus the three families of inputs it consumes. This clearly separates it from generic siblings like salaire_brut_en_net or freelance_tjm_ca_net, though it doesn't name a sibling explicitly to sharpen 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?

No indication of when to pick this over the closest alternatives (freelance_tjm_ca_net, comparatif_statuts, auto_entrepreneur). No prerequisites, no note on whether tjm or caMensuel should be supplied. The agent must infer usage purely from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is fully covered and the description carries a lighter burden. It usefully states that the result is a duration plus an end date, but adds nothing about how legal/conventionnel precedence is arbitrated at runtime or what happens when required data is missing.

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 naming the computation, its outputs, and the starting input, with no filler. The parenthetical rupture-type list earns its place by scoping the tool.

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

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

With no output schema, the description does the necessary work by naming both return values (durée and date de fin). For a nine-parameter, two-required pure calculation tool the main remaining gap is per-type parameter applicability, which the schema partially covers via its enum documentation.

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 67%, so roughly a third of the nine parameters (cadre, ancienneteMois, ancienneteAnnees) are documented only by name. The description does not clarify which optional parameters matter for which rupture type (e.g. presenceJours only for essai, dureeConventionnelleMois only when more favourable), so it adds little beyond the schema's own enum 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?

Specific verb (calcule) plus two concrete outputs (durée du préavis, date de fin) and an explicit input basis (date de notification). It also enumerates the covered rupture types (démission, licenciement, rupture de période d'essai), which cleanly separates it from siblings like indemnite_licenciement or rupture_conventionnelle.

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: the sentence establishes that the calculation starts from the notification date, so an agent can infer it is a calculation helper. There is no explicit when-to-use/when-not statement and no sibling is named as an alternative, even though indemnite_licenciement and rupture_conventionnelle overlap in domain.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is clear. The description adds that this is an estimate based on income and household composition, but it does not clarify whether the result is an official simulation, what assumptions are used, or whether eligibility is checked.

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 with no filler or repetition. It is appropriately concise, though for an eight-parameter calculator it leaves useful context to the schema rather than using a second sentence to clarify scope.

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 eight-parameter benefit simulation with no output schema, the description is too sparse: it does not explain the optional versus required inputs, the compatibility fields, or the estimation assumptions. The schema and annotations provide some support, but the description does not fill the remaining contextual 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?

The description broadly maps to revenusMensuels and the household-composition fields through "revenus d'activité" and "composition du foyer." With 63% schema description coverage, the schema already documents several parameters, but the description does not explain logement enum values, aideLogement, revenusConjoint, or autresRessources.

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

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

The description names a specific verb and resource: "Estime la prime d'activité mensuelle." It also scopes the estimate by income and household composition, making the tool identifiable, but it does not differentiate it from sibling financial simulators such as allocation_chomage or simulation_apl.

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 phrase "selon les revenus d'activité et la composition du foyer," so an agent can infer when to use it. However, the description gives no explicit when-to-use guidance, no exclusions, and no comparison with sibling benefit calculators.

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

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

Annotations already declare a pure read-only, idempotent, closed-world computation, so the safety profile is covered. The description adds value by enumerating what is actually computed (including trimestres validés and IJ maladie, which an agent could not guess), but it omits that results are rule-dependent estimates (schema cites 2026 parameters and specific décrets) and says nothing about precision, rounding or caveats.

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 the computed outputs enumerated, no filler. It is slightly dense in how it stacks four output types, but 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?

With no output schema, the description does the necessary job of naming the returned figures, which is the key completeness requirement here. However, for a four-parameter tool with two undocumented parameters and regime-dependent branching, the description leaves the agent without enough to know which inputs are expected together (e.g. activiteMicro vs profession).

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 only 50%; regime and profession have no descriptions at all, and the description does not explain how the micro vs réel choice or the profession changes the calculation. It only implicitly maps revenusAnnuels ("selon son revenu annuel"), leaving the agent to infer the branching logic of four parameters from enums alone.

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

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

Specific verb ("Estime") plus a well-defined resource set: cotisations retraite base/complémentaire, prévoyance, trimestres validés and IJ maladie for an indépendant. It is clearly distinct from siblings like salaire_brut_en_net or seuils_micro_entreprise, though the description never explicitly says how it differs from auto_entrepreneur or comparatif_statuts, which also deal with self-employed contribution regimes.

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 or when-not-to-use guidance and no named alternative. Given the sibling list contains auto_entrepreneur and comparatif_statuts that plausibly overlap on self-employed social contributions, the absence of routing guidance is a real gap; the only hint is the implicit "selon son revenu annuel" 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?

Annotations already declare a pure, idempotent, closed-world read, so the safety profile is covered. The description adds real context by explaining the two outputs (minimum indemnity and the cotisations/CSG/impôt breakdown of a negotiated amount), but it is silent on defaults for the ten optional parameters and on how the chosen barème year changes results.

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 tight sentence with no filler, front-loading the primary computation and appending the conditional secondary output. Efficient, though it leaves no room for the parameter guidance the low schema coverage demands.

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 11-parameter tool with no output schema and sparse parameter documentation, the description is too thin: it does not say what happens when optional inputs are omitted, what the result contains, or how convention/anneeBarèmes affect the calculation.

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 only 27% across 11 parameters, so the description should have compensated, and it does not. It only echoes indemniteNegociee (already documented) and never clarifies the relationship between ancienneteAnnees/ancienneteMois, which salary fields drive the reference salary, or what convention and tauxCotisations expect.

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: computing the minimum statutory indemnity for a rupture conventionnelle, plus the conditional tax/social-treatment split when a negotiated amount is supplied. It is clearly distinct from a generic severance calculator, though it never names the closest sibling (indemnite_licenciement) to sharpen 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?

The conditional clause 'si un montant négocié est donné' implies the optional branch (leave it out and you only get the minimum indemnity), which is useful implied guidance. But there is no explicit when-to-use/when-not, no statement of prerequisites (convention collective, barème year), and no routing to alternatives.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the description's added value is the output shape: net before and after withholding tax, on monthly/annual/hourly bases, with a 2026 employee-contribution breakdown. The year reference is meaningful because it tells the agent which rule set is applied, though it does not say whether results are estimates or how the withholding rate is resolved.

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 dense sentences with no filler; the conversion direction comes first, output scope second, supported statuses last. Nothing is repeated from the title or schema.

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

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

With 8 parameters, no output schema, and a read-only annotation set, the description does the essential work of enumerating what comes back at a high level. The gaps are the omitted 'portage' status and the unexplained optional inputs, which leave some ambiguity for a parameter-heavy simulation.

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 only 38%, so the description should compensate more than it does: it names four of the five statut enum values (omitting 'portage', which the schema allows) and hints at the withholding-tax parameter via 'prélèvement à la source'. It says nothing about moiPrime, primesAnnuelle, heuresSupMensuelles, or tempsTravailPercent.

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 ('Convertit un salaire brut mensuel en net') plus the full output scope (avant/après impôt, mensuel, annuel, horaire, détail des cotisations 2026). The direction of conversion is unambiguous, which implicitly separates it from the sibling salaire_net_en_brut without needing to name it.

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

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

The description makes the use case implied (a gross-to-net salary simulation) but never states when to prefer it over salaire_net_en_brut, comparatif_statuts, or portage_salarial, nor any prerequisites. The agent must infer the routing from the name and the direction wording.

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

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

Annotations already declare a read-only, idempotent, closed-world computation, which is the main behavioral profile needed here. The description adds one useful semantic detail — the input net is before income tax — and notes the output mirrors the sibling's breakdown, but does not say what that breakdown actually contains or how it scales with the optional parameters.

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

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

A single front-loaded sentence that leads with the computed quantity and its input. Tight overall; the only soft spot is the trailing cross-reference to salaire_brut_en_net, which conveys format expectations rather than routing 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 six-parameter financial calculator with no output schema and no parameter documentation, the description is too thin. Optional inputs like part-time percentage, bonus month and monthly health insurance materially change the result, yet nothing explains their effect or units.

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% across six parameters, so the description carries the full burden. It only clarifies netMensuel (net, before tax) and leaves statut, moisPrime, mutuelleMensuelle, tempsTravailPercent and tauxPrelevementSource entirely unexplained beyond their names.

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: recover the monthly gross salary matching a given net monthly figure. It also distinguishes direction from the sibling salaire_brut_en_net by framing this as the inverse computation. The reference to 'the same detail as salaire_brut_en_net' is slightly circular, but the core operation 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?

Direction of use is implied by 'corresponding to a net monthly before tax', so an agent can infer this is the tool to pick when it holds a net figure. However, it never explicitly says when NOT to use it, nor does it frame salaire_brut_en_net as the alternative for the opposite direction, only as a formatting reference.

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

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

Annotations already declare readOnlyHint/idempotent/openWorld=false, so this is clearly a safe deterministic computation and the description needn't restate that. It adds the useful detail that the comparison is against 2026 rules, but says nothing about what is returned (a verdict? both thresholds? a status per regime) despite there being no output schema.

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

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

One tight, front-loaded sentence with no filler. It is efficient, though arguably too terse for the decision-support nature of 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?

For a rule-evaluation tool with no output schema, the description should state what result comes back and how to read it (e.g., threshold exceeded vs. franchise maintained). It also leaves the mixed-activity path undocumented. As written, the agent knows what the tool is about but not what it will get.

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 75%, so the schema carries most of the meaning, including the activity enum values and the 'mixte' branch. The description adds no parameter-level information — nothing on how caAnnuel vs caServicesMixte interact or when depassementAnneePrecedente matters.

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

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

Specific verb ('Situe ... par rapport aux plafonds') plus two concrete resources: micro-entreprise ceilings and 2026 VAT franchise thresholds. An agent can tell this is a threshold-positioning calculation. It does not, however, distinguish itself from overlapping siblings such as auto_entrepreneur or tva_freelance.

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 when-to-use statement, no exclusions, and no pointer to the clearly overlapping siblings (auto_entrepreneur, tva_freelance, freelance_tjm_ca_net). The agent must infer the use case entirely from the one-line purpose.

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

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

The annotations already establish that this is a read-only, idempotent, closed-world operation, so the safety profile is covered. The description adds only that the result is an estimate, without explaining assumptions, precision, or any limitations of the calculation.

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 efficient sentence with the main action and factors front-loaded. There is no filler or redundancy.

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

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

For a simulation tool with 10 parameters, no output schema, and low schema description coverage, the description is too sparse. It does not explain the return format, calculation assumptions, or enough optional-parameter semantics to fully guide correct invocation.

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

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

The description groups the core inputs into rent, income, household composition, and zone, which adds some meaning beyond the schema. Yet schema description coverage is only 30%, and the description does not clarify the boolean flags, the zone enum values, or the relationship between monthly income and annual resources.

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, "Estime," and a specific resource, "aide personnalisée au logement (APL)," plus the main factors considered. This makes the tool clearly distinguishable from the payroll and tax calculators listed as siblings.

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

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

The tool's purpose implies when it should be used: to estimate APL from rent, income, household composition, and zone. However, the description gives no explicit guidance on when to choose it, exclusions, prerequisites, or comparisons with any alternative tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered and the bar is lower. The description adds the useful fact that this is an estimation ('Estime') covering a named set of payout components, but says nothing about underlying assumptions, default handling, or that the result is an estimate rather than an authoritative payroll calculation. Adequate with annotations, but thin on substance.

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 with the operation front-loaded and the output components enumerated in a compact list. Zero filler, nothing repeated from the schema or the title.

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

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

For a 12-parameter, legally involved calculator with no output schema, the description does at least tell the agent what the returned figures will be. But it leaves open whether optional inputs (tauxCotisations, joursAcquisPeriode, decompteConges) are needed for a usable result, how components interact, and whether the tool returns a breakdown or a single total. Adequate but with clear gaps for the tool's 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 coverage is 83%, so the schema carries most parameter meaning and baseline 3 applies. The description adds a loose mapping from components to inputs (préavis → preavisNonEffectueMois, 13e mois → moisPourTreizieme, prime de précarité → remunerationTotaleCDD, indemnité de rupture → indemniteRupture) which helps an agent understand which inputs unlock which outputs, but no format, dependency or default guidance.

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

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

The description uses a specific verb ('Estime') and a specific French payroll resource ('solde de tout compte'), then enumerates the six components computed (dernier salaire, congés non pris, préavis, 13e mois, prime de précarité, indemnité de rupture). An agent can tell exactly what it produces. It does not, however, name or distinguish itself from close siblings such as indemnite_licenciement, rupture_conventionnelle or conges_payes_indemnite, 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 guidance and no mention of alternatives, even though several siblings overlap heavily (indemnite_licenciement, rupture_conventionnelle, conges_payes_indemnite, preavis). The end-of-contract context is only implied by the term 'solde de tout compte' itself. The agent must infer routing from French labour-law domain knowledge.

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

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

Annotations already declare readOnlyHint, idempotentHint, and closed-world, so the safety profile is covered. The description adds one genuine behavioral fact beyond that: the result is conditional (a VAT amount vs. a franchise-en-base indication), which matters for interpreting the response. It omits any mention of how the optionTVA or deductible-VAT inputs change the outcome.

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 calculation target stated first and the conditional outcome second. No filler, no restatement of the tool name.

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

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

With six parameters, no output schema, and partial schema descriptions, the description should clarify the required turnover input and what the response contains in the franchise case. It hints at the two possible outputs but leaves the enum and the required numeric input undocumented.

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 67%, leaving 'activite' (enum, undescribed) and the required 'caHTAnnuel' with no descriptive text anywhere. The description only alludes to these two inputs and adds no semantics for the enum values, the optionTVA switch, or the deductibility inputs beyond what the schema already says.

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: compute VAT to charge (facturer) and remit (reverser), or return the base franchise regime, depending on activity and turnover. That is clearly a calculation tool, distinguishable from the neighboring 'seuils_micro_entreprise' only indirectly – the description never says whether it tests thresholds or just applies 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 inputs (activity + annual turnover), but the description gives no explicit when-to-use or when-not-to-use guidance and names no sibling as an alternative. An agent cannot tell from the text alone whether to call this or 'seuils_micro_entreprise' first.

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