Marcel

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description goes further by disclosing which parameters fall back to published hypotheses (Livret A rate, Banque de France rate/duration, notary fees, constant prices/rents) and by stating the response contains no decision field and only up to two clarifying questions ('a_demander'). That is meaningful behavioral context beyond the annotations.

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

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

Purpose is front-loaded, followed by inputs, defaults, output shape, and caveats in a logical order. The single long sentence about defaults is dense but each clause (taux, durée, frais de notaire, évolution) earns its place; there is little filler.

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

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

For a 21-parameter tool with no output schema, the description supplies the return structure (year-by-year wealth gap, point_mort, four cost blocks, hors_assurance, a_demander, grid), which the schema cannot convey. It is complete enough to call correctly, though the absence of explicit usage routing leaves one gap.

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

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

The description lists the input families (prix, apport, loyer, crédit, frais, département, date d'acte, charges, horizon, hypothèses) and, more importantly, explains the default behavior for omitted values tied to hypothesesVersion/hypotheses. With schema coverage at 57%, the prose compensates for the undocumented parameters, though not exhaustively for all 21.

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 opening sentence states a precise verb and resource: comparing the wealth trajectory of a primary-residence buyer versus a renter over time. That object is unambiguous and clearly distinct from the sibling simulation tools (pension, AV, CTO, IFI), so an agent can route here without opening the schema.

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

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

The description defines the input domain and the default-hypothesis behavior, which implies when the tool applies, but it never states when to prefer it over an alternative or names any sibling. It also flags that default-based results are 'indicatif', a useful caveat, yet provides no explicit when-to-use guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed world), and the description adds genuine behavioral detail beyond them: pensionNetMonthly is null unless rfr is provided, and without rfrPrecedent the median/normal rate is skipped and the result is a reduced-rate estimate. This conditional-output behavior is exactly the kind of context annotations cannot convey.

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

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

Front-loads the purpose, then groups inputs, then output behavior in three sentences with no filler. Dense but every sentence carries information; only the long input enumeration is slightly list-like.

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

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

For a 13-parameter tool with nested objects, no output schema, and thin schema descriptions, the definition covers purpose, the key output field (pensionNetMonthly) and the rfr/rfrPrecedent conditions well. Remaining gaps concern the meaning of the less-common numeric inputs, which lowers it from a 5.

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 23%, so the description must compensate: it enumerates most inputs (birth year/month, retirement age, regime, SAM, quarters, Agirc-Arrco points, liberal-career elements, rfr/rfrPrecedent) and clarifies the rfr/rfrPrecedent relationship (previous year = rfr year minus one). But it gives no semantics for samSaisi, trimestresRG, pointsCNAVPL, etc., so the low-coverage gap is only partly filled.

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 ("Estime") and resource ("pension de retraite brute"), so an agent knows exactly what is computed. It is clearly distinct from the simulate_* siblings by domain (retirement pension), though it never names or routes to an alternative explicitly.

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

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

Implicit guidance is present: the description explains that the result is "indicatif" without rfrPrecedent and that the net field is only populated when rfr is supplied. However, there is no explicit when-to-use / when-not-to-use framing or reference to the many simulate_* sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds meaningful behavioral context beyond them: it explains that missing transmission inputs cause refusal, that netRachat is a contract net distinct from household net, and details the age-based transmission tax regime and allowance sharing.

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

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

The description is dense but front-loaded: purpose first, then inputs, outputs, the netRachat caveat, the transmission regime, and the refusal condition. Every sentence contributes to a complex tax-calculation tool, though the paragraph could be slightly more scannable for 15-parameter invocation.

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

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

Given the tool's complexity (15 parameters, nested arrays, no output schema), the description adequately covers purpose, required inputs, output amounts, tax regime rules, and refusal conditions. It lacks explicit sibling-tool routing and does not explain all optional parameter nuances, but the schema and annotations fill most remaining gaps.

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

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

With 67% schema description coverage across 15 parameters, the schema carries much of the load. The description names the main required inputs and the transmission-specific structures (primesParAge, beneficiairesTransmission with lien and quote-part), but it does not clarify several optional parameters such as tmi, plusValuesUC, primesAvant2017, or the significance of ageAssure versus age at payment.

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: calculating the tax treatment of a life insurance contract (assurance-vie), with explicit modes rachat, avance, and transmission. The resource clearly distinguishes it from sibling simulators for CTO, PEA, PER, IFI, and Dutreil, so an agent can route correctly without opening the schema.

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

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

Explains the required inputs and that transmission calculation is refused without primesParAge or beneficiairesTransmission, which gives clear invocation conditions. However, it does not explicitly say when to use this tool versus sibling simulators such as simulate_cto or simulate_pea, so usage guidance remains implied rather than explicit.

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

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

Annotations already establish the safe, deterministic profile (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower; the description still adds real behavior: output split into IR and prélèvements sociaux, the default-vs-option fallback behavior, and the loss-offset/carry-forward rule. It stops short of 5 only because permission/dependency requirements are not discussed.

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?

Purpose and scope are front-loaded, followed by inputs, outputs, default behavior, and conditional behavior in a logical order with no filler sentences. It is dense and somewhat long, but each clause carries information an agent needs.

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

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

With 13 optional parameters and no output schema, the description carries the burden well: it enumerates the input categories, states the return structure (IR and PS, separated), and explains the conditional regimes. Nothing essential for calling it correctly appears missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds domain meaning the schema does not: losses impute only against gains with a ten-year carry-forward, the abattement for pre-2018 holdings applies only under the barème option, and the fallback behavior when parts/revenuImposableHorsPfu are absent.

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 ... la fiscalité d'un compte-titres ordinaire d'une personne physique') with the governing CGI articles, which cleanly separates it from the sibling simulators (simulate_pea, simulate_av, simulate_ifi, simulate_dutreil, simulate_per_sortie). An agent can route to it without opening any schema.

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

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

It sets the default regime ('Par défaut, prélèvement forfaitaire') and the exact conditions under which the barème alternative is computed ('lorsque le revenu imposable hors ces revenus et le nombre de parts sont fournis'), which effectively guides invocation. It does not, however, explicitly name or exclude sibling tools, so it stops short of a 5.

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

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds substantial contextual behavior: the 2026 vs 2027 regime switch, the 98.25% abatement before 2027, that totalRetenu becomes activity income only after 2027, that totalRetenu is null when no plafond applies, and the default behavior (avertissements) when the date is absent.

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?

Dense but well front-loaded: purpose and legal basis first, then Entrées, then Sortie, then the regime mechanics. Every sentence carries domain information, though the enumeration of inputs is somewhat redundant with a 100%-covered 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 no output schema, the description carries the return-value burden and does so (montants bruts mensuels, régime applicable, totalRetenu, assiette comparée au plafond). Combined with the legal-transition and null-semantics notes, an agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema for dateEntreeJouissance, explaining it selects the applicable droit and that its absence falls back to rules in force until 31 December 2026. The remaining parameters are enumerated without much extra syntax detail.

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

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

States a specific verb (calcule) and resource (cumul emploi-retraite) with the two possible outcomes (cumul intégral ou plafonné) and the écrêtement mechanism. Scope boundaries are explicit, ruling out indépendants, fonction publique and régimes spéciaux, which cleanly separates it from sibling simulate_* tools.

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

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

Exclusions are clearly stated (indépendants, fonction publique, régimes spéciaux hors de ce calcul), and it explains that dateEntreeJouissance selects the applicable droit. However, it never names a sibling tool or says when to prefer this over alternatives, so it falls short of an explicit when/when-not routing.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add context, which it does: it names the output (fiscal cost per path) and discloses conditional behavior – a temporal-conflict warning is emitted when the sale horizon does not exceed the sum of the collective and individual commitment durations. It stops short of describing the exact return shape or units.

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

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

Three tight sentences: purpose first, inputs second, output and edge-case behavior third. No filler, and the warning condition is stated where an agent will see it.

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 tool with no output schema and sparse schema descriptions, the definition covers the essentials (inputs, output, one warning case). Gaps remain: units for the duration/horizon parameters, defaults for the four optional inputs, and the treatment of tmiFrance, which the schema says does not enter 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 13%, so the description must compensate. It enumerates seven of the eight inputs (share value, cost basis, number of children, director age, sale horizon, collective and individual commitment durations), which helps agents map business concepts to parameters, but it adds no units, defaults, or constraints for the optional 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?

States a specific verb (Calcule) and a precisely scoped resource: four business-transmission paths with and without the Dutreil pact, anchored to CGI art. 787 B. This clearly separates it from siblings like simulate_av, simulate_cto, or simulate_ifi, which cover other tax vehicles.

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 input list implies the context (business owners planning a transfer with children), but the description never says explicitly when to pick this tool over the other simulate_* siblings, nor does it state preconditions or 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?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false). The description adds useful behavioral context beyond annotations: the décote is returned as a separate line (ligneDecote), quotePartImmo maps to the SCPI real-estate share, and the plafonnement uses the provided revenu fiscal de référence. It does not fully describe the output shape, but with no output schema it is reasonably transparent.

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

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

The description is dense but front-loads purpose, then inputs, output, and special calculation rules. Every sentence earns its place, though the single-paragraph French structure could be more scannable with separation between inputs, outputs, and caveats.

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

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

Given a complex tax simulation with no output schema, the description adequately covers purpose, required inputs, output value, and special rules (décote threshold, plafonnement). Annotations handle safety, and the schema handles structural validation; remaining gaps are detailed meanings of nested enum/boolean fields, which are minor for correct invocation.

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

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

Schema description coverage is 0%, so the description must supply parameter meaning. It lists the main top-level inputs and clarifies quotePartImmo for SCPI, but it omits details for nested fields such as the actif 'type' enum values, the passif 'deductible' flag, and the role of 'age'. It adds partial semantic value but does not fully compensate for the empty schema descriptions.

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

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

States a precise verb ('Calcule') and resource (IFI), with legal references and the exact components computed (assiette, barème, décote, plafonnement). An agent can immediately distinguish this from sibling simulations like simulate_av or simulate_pea.

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 clear context by naming the domain (IFI) and listing required inputs, which implies when the tool is relevant. However it does not explicitly state when to use it versus sibling tools, nor does it mention exclusions or alternatives.

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

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

Beyond the read-only/idempotent annotations, the description discloses the tax regime after 5 years, the distinct social-levy treatment versus assurance-vie, the returned figures, and the caveat that without versementsTotal gains are not estimated. This adds substantive behavioral context 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?

The description is front-loaded with purpose, then lists inputs, outputs, a tax rule, and a caveat. It is dense but appropriately sized for a complex fiscal simulator, though the single long paragraph could be structured more sharply.

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 supplies the return values and a key tax rule. It is fairly complete for a multi-mode tax calculator, but it omits the pre-5-year PEA regime and does not detail how rente or rachat partiel are treated.

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 already 89%, so the description need not repeat every parameter meaning. It still adds cross-parameter semantics: versementsTotal controls whether gains are estimated, ancienneteAns drives the 5-year threshold, and the objetCalcul modes are enumerated.

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 la fiscalité d'une sortie de PEA', then scopes it with the four calculation modes. It also distinguishes the PEA social-levy treatment from assurance-vie, which helps separate it from the sibling simulate_av 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?

The description makes clear this is for PEA exit taxation and lists the calculation modes that select the tool's use. It does not explicitly name which sibling to use instead in all cases, though it does contrast the tax rate with assurance-vie.

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

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

Annotations already establish readOnly/idempotent/non-destructive, so the bar is lower, yet the description goes further by disclosing the output semantics (impôt sur le revenu = foyer barème difference with vs. without the flow, plus prélèvements sociaux) and the tax-law treatment for capital vs. rente. It omits edge behavior such as rounding, error cases, or multi-year (horizonAns) handling, keeping it from a 5.

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

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

Purpose and inputs are front-loaded before the denser tax-treatment detail, and the length is justified by the tool's complexity. There is mild redundancy ('même différence de barème' restated for rente), but overall every sentence carries substance.

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

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

With no output schema, the description correctly carries the burden of describing the return values and the tax logic. It is complete for the capital/rente paths but leaves the reversible-annuity and multi-year parameters (tauxReversionConjoint, horizonAns, rendementAnnuel) 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%, so schema does most of the work and baseline is a 3. The description usefully clarifies tmiRetraite as a distinct comparison input and lists the main entries, but three parameters (horizonAns, rendementAnnuel, tauxReversionConjoint) receive no explanation in either schema or description, so it does not fully close 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 opens with a specific verb+resource ('Calcule la fiscalité d'une sortie de PER') and enumerates the four supported calculation modes (capital, rente, rente réversible, comparaison). It is clearly distinct from the product-specific siblings (simulate_av, simulate_cto, simulate_pea) but never names an alternative to route against.

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 through the objetCalcul modes and the note that tmiRetraite 'sert à la comparaison'. There is no explicit when-to-use guidance, no prerequisites, and no statement of when NOT to use this tool versus the other simulate_* siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real value beyond that: it names the exact output behaviors (status 'blocked' on TEMPORAL_CONFLICT or a blocked engine, plus a stale-rule warning) and gives a concrete rule example (CGI.200-A.PFU_30PCT since 2026-01-01).

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 that front-load the purpose before input and output details. Information density is high with little filler, though the final clause carrying the concrete rule example is somewhat packed.

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 one array parameter, no output schema and no annotation detail on returns, the description carries the output burden and handles it by naming the blocked/conflict/stale-rule outcomes. It stops short of describing the full response shape or how multiple conflicts/warnings are aggregated, but it is adequate for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It enumerates the item fields (moteur, identifiant de trace, statut, version de règles, résultat), mapping well onto engine, traceId, status, rulesVersion and result, which genuinely helps. But it adds no types, formats, or semantics beyond the field names, so it only partially covers the 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 and resource: 'Contrôle la cohérence de plusieurs résultats Marcel', and outlines both input and output, which is far more than a name restatement. It is implicitly distinguishable from its simulation siblings, though it never explicitly contrasts itself with them (e.g. compare_certified).

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 described input (a list of results) and output (blocked status / stale-rule warning), so an agent can infer this runs as a consistency check over results. However, there is no explicit statement of when to call this versus the sibling simulation tools, nor any prerequisite or sequencing guidance.

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