tax-retirement

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows it's a safe, side-effect-free operation. The description adds value beyond annotations by detailing the calculation formula, the components (IR, PFU, CEHR, majorations), and the stateless nature. It also provides legal sources. No contradiction with annotations, and the added context about the algorithm is useful.

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

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

The description is dense but every sentence carries value: it states the purpose, gives the formula, names the distinct tool, and cites sources. It is front-loaded with the name and core function. Though lengthy, it is not verbose—it efficiently packs essential legal and technical detail without fluff.

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

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

Given the complexity of a French tax calculation, the description provides the full formula and legal references, and the schema covers parameter defaults and constraints. However, since there is no output schema, the description does not explicitly state the return format (presumably the CDHR amount in euros). This is implied but could be clearer. Overall, it is quite complete for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so all seven parameters are documented in the schema. The description adds meaning by explaining how parameters like rfr_ajuste, impot_reference, and revenus_financiers_pfu fit into the overall formula, giving context beyond individual definitions. This clarifies the relationships between parameters, which is more than the baseline 3 for high 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?

The description clearly states the tool computes the CDHR (Contribution différentielle sur les hauts revenus) and provides the exact legal formula (art. 224 CGI). It explicitly differentiates from the sibling fiscal_cehr, naming the CEHR and its article, so an agent can unambiguously distinguish it. The verb is implicit ('compute') but the resource and scope are fully specified.

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

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

The description explicitly says 'DISTINCTE de la CEHR (art. 223 sexies)', which tells the agent this is not the CEHR tool. It also mentions 'Version stateless', implying it's a pure calculation without side effects. However, it does not explicitly enumerate when to use this tool versus other fiscal tools (e.g., fiscal_impot_revenu), though the specialized nature makes it fairly obvious. The alternative is named, so a 4 is appropriate.

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 the tool readOnly and idempotent, so safety-related behavior is covered. The description adds legal context and identifies RFR as the basis of CEHR, but it does not explain what the tool returns or whether it produces zero below the applicable thresholds, even though there is no output schema to clarify this.

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 short, front-loaded with the tax definition, and includes a useful distinction from CDHR plus legal sources. The full tax name is repeated from the annotation titleessed, but the overall structure is economical and every sentence has a purpose.

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

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

For a two-parameter read-only calculator with well-described inputs)SkipThis is largely sufficient: it identifies the tax, its legal base, the relevant fiscal income, and the CDHR distinction. The main gap is the lack of an explicit output description, which matters because no output schema is present.

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

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

The input schema provides complete descriptions for both parameters, including the household-status thresholds in the situation enum. The prose description merely repeats 'revenu fiscal de référence' and adds no parameter meaning beyond what the schema already documents, so the baseline of 3 applies.

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

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

The description clearly names CEHR, ties it to the revenu fiscal de référence, and cites the relevant legal source, so an agent can identify the tax being handled. It also explicitly distinguishes CEHR from CDHR, which helps avoid confusing the closest sibling. However, it lacks an explicit action verb such as 'calcule' or 'retourne', so the tool's exact behavior is inferred 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 phrase 'Distincte de la CDHR' gives an implicit exclusion and signals that this tool is not for the CDHR computation. But the description does not explicitly say when to use this tool versus fiscal_cdhr or any other fiscal_* sibling, so usage guidance remains mostly implied.

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

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

Beyond the readOnly and idempotent annotations, the description adds meaningful behavioral detail: the tax rates involved, the 40% dividend allowance, the deductible CSG, the 2026 social contribution rates by type, and the stateless nature of the computation. It does not contradict the annotations and gives useful context without overclaiming.

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 efficient: the core comparison and decision outcome are front-loaded, followed by the relevant rates and statutory sources. Every clause carries information needed for a tax tool, though the source citations could arguably be moved to metadata without losing agent-facing value.

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

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

For a complex tax comparison with no output schema, the description provides the essential context: the regime options, the applicable rates, the legal bases, and the expected conclusion of which option is more favorable. It could more explicitly state the output shape or edge-case exclusions, but the information provided is sufficient 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 coverage is 100%, so the baseline is 3. The description adds value by explaining the tax logic that links parameters: PFU at 12.8% IR plus social contributions, the 40% dividend allowance, and how the option barème interacts with marginal IR and the taxable income. This enriches understanding of type_revenu and montant beyond the schema.

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

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

The description states a clear, specific task: compare capital income taxation under PFU flat tax versus the progressive barème option and identify the more favorable option. It is unambiguous about the resource and the output, and it is clearly distinct from sibling tax tools by its comparative scope.

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

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

The description makes the intended use case clear: it is for capital income where both PFU and the barème option apply. It does not explicitly name sibling alternatives or state exclusions, but the subject is narrow enough that the agent can infer when to 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?

The description goes well beyond the read-only and idempotent annotations by disclosing that the cap (plafonnement) applies only when both revenu_foyer and autres_impots_annuels are provided, otherwise the IFI is returned uncapped. It also clarifies the stateless nature (no file reading) and cites legal sources. This adds substantial behavioral context that an agent needs to predict the tool's response under different inputs.

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 efficiently organized: it opens with the tax name, then explains the key calculation rules and conditions, notes the stateless behavior, and ends with legal sources. Every sentence contributes to understanding the tool's behavior or constraints, with no redundant repetition of the schema. The front-loaded purpose and structured flow make it easy for an agent to parse.

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

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

The description covers the essential calculation logic, including the conditional cap and the debt limitation threshold, and states the stateless nature. It does not explicitly describe the return value (the computed IFI amount), but that is implicit from the purpose and the lack of an output schema. Given the tool's complexity, it would benefit from a brief note on the output format, but overall it provides sufficient context 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 coverage is 100% and each parameter already has a descriptive comment. The description enriches this by providing the legal framework (articles 974, 977, 979) and the numerical thresholds (1.3M, 800k, 5M), and by explicitly connecting the cap condition to the parameters. It clarifies that patrimoine_immobilier_taxable is before debts and includes specific asset types, reinforcing the schema's definition. This adds meaningful context beyond the basic parameter 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?

The description explicitly states the tool computes 'Impôt sur la fortune immobilière (IFI)' and details the calculation rules (debt limitation, progressive scale, discount, cap), making its purpose unmistakable. It clearly distinguishes itself from sibling fiscal tools that handle other taxes (e.g., CDHR, CEHR, income tax). The specific legal references and thresholds further cement its identity.

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 purpose is so specific that an agent can infer when to use it (any IFI calculation), and the description notes the stateless nature and the condition for the cap. However, it does not explicitly name alternatives or state when not to use it, relying instead on the tool's unique domain. Since the sibling tools are clearly distinct (e.g., fiscal_impot_revenu for income tax), the usage context is clear but not explicitly 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?

Les annotations readOnlyHint et idempotentHint couvrent déjà l'absence d'effets de bord. La description ajoute un contexte utile sur les règles de calcul incluses (plafonnement du quotient familial, décote), l'année des revenus concernés (2025) et les sources légales, dépassant ce que les annotations fournissent.

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

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

La description est compacte, place l'objet en tête et regroupe les informations clés dans des parenthèses, avec les références légales en fin. Une légère redondance avec le titre existe, mais elle reste mineure et ne nuit pas à la lisibilité.

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

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

Pour un outil de calcul sans schéma de sortie, la description précise l'assiette, la méthode, l'année et les sources, ce qui permet à l'agent de comprendre le périmètre. Le format exact du résultat reste implicite, mais l'objet « impôt » rend la finalité suffisamment claire.

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?

La couverture du schéma est de 100 % : les trois paramètres (parts, situation, revenu_net_imposable) sont déjà documentés avec leur rôle. La description n'apporte pas de sémantique supplémentaire au-delà du contexte fiscal et de l'année d'imposition, donc elle reste au niveau de référence.

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

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

La description identifie clairement l'outil comme le calcul de l'impôt sur le revenu brut d'un foyer, avec le barème 2026, le quotient familial plafonné et la décote, ce qui le distingue implicitement de fiscal_tmi ou fiscal_ifi. Il manque toutefois un verbe d'action explicite comme « calcule » et aucune mention directe d'un outil frère.

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?

Le texte n'indique pas explicitement quand utiliser cet outil plutôt que fiscal_tmi, fiscal_flat_tax_vs_bareme ou fiscal_ifi. Le cas d'usage est néanmoins implicite grâce aux termes « revenu brut d'un foyer » et « barème progressif », ce qui guide l'agent sans formuler d'exclusion.

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 and idempotentHint=true, so the safety profile is covered. The description adds meaningful context: it is stateless, based on the law text with a BOFiP expected, and explains the formula (80% of price, rate based on type, cap, deductible). It also warns that calculations are provisional pending BOFiP. This goes beyond the annotations and gives the agent a clear model of the tool's behavior.

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

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

The description is long but dense and well-structured, with a warning about BOFiP and sources at the end. Every sentence contributes either to purpose, formula, or caveats. It is front-loaded with the core purpose and device name. It is not overly verbose for the complexity of a French tax incentive calculation.

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

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

Given no output schema, the description clearly states what it returns (annual depreciation and tax savings for 1 and 9 years). It explains all input parameters' roles (though the schema does too) and adds the legal basis and caveat about BOFiP. For a read-only calculator with idempotent behavior, nothing essential is missing for an agent to call 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% with each parameter described. The description adds value by explaining the 80% amortizable basis (terrain forfait 20%) and the TMI override logic (tmi_pourcentage bypasses derivation from revenu_net_imposable). This is beyond what the schema states, enriching the meaning of the parameters.

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

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

The description clearly states a specific verb ('Calcule') and resource ('amortissement annuel retenu et l'économie d'impôt'), identifies the device (Dispositif Jeanbrun, successeur de Pinel), and provides the legal reference (LF 2026 art. 47). It is unmistakably distinct from the many other fiscal_* siblings because it names a unique tax incentive with a specific calculation scope.

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

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

The description explains the tool's role and context (successor of Pinel, window 21/02/2026→31/12/2028) but does not explicitly name alternative tools or state when not to use it. However, the specificity of the device makes it obvious which scenario it addresses. It lacks an explicit 'use X instead' pointer, which the high example had, so not a 5.

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

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

The annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and side effects. The description adds meaningful behavioral detail beyond the annotations: the 10,000 € / 18,000 € thresholds, the list of excluded niches (dons Coluche, Malraux, Monuments historiques, déficit foncier, PER), and the legal sources. This substantially helps an agent understand what the computation respects.

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 tightly written: the main purpose and thresholds are front-loaded, followed by exclusions and input note. The sentence 'La liste des niches est fournie en entrée' is somewhat redundant with the schema, and the legal citations are extra, but they are relevant and do not bloat the description.

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 has no output schema, the description should state what the tool returns (e.g., the calculated capped tax reduction or the total reduction after global capping). It does not. It covers the rule, thresholds, exclusions, and input well, but the missing return contract is a real gap for an agent selecting and invoking the tool.

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

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

Schema description coverage is 100%, so the schema already documents the single `niches` array parameter and its object shape. The description adds domain context about which niches are in or out of the cap, but it does not expand on the accepted `type` values beyond the schema examples, nor does it clarify output semantics.

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 title and description clearly identify the resource: the global cap on tax niches ('Plafonnement global des niches fiscales') under CGI art. 200-0 A, with the main thresholds stated. It is distinguishable from sibling tax tools (e.g., fiscal_impot_revenu, fiscal_ifi) by its specific focus on niche capping. However, it lacks an explicit verb such as 'calculate' or 'returns', and does not explicitly name sibling distinctions.

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 when to use the tool: when applying the global cap to a provided list of tax advantages. It also clarifies important scope exclusions ('Certaines niches sont HORS plafond'). It does not explicitly describe when not to use it or point to alternative tools, leaving routing partially implicit.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds behavioral context: it is stateless, performs a complete recalculation of multiple taxes, and accounts for the CDHR cap, explaining that the marginal gain can be ~20% rather than the TMI. This goes beyond the annotations and helps the agent understand the computation's nature.

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 paragraph that packs the core purpose, a formula, a critical warning, a stateless note, and legal references. Every sentence adds value, though the legal citations could be considered optional. It's front-loaded with the main purpose and remains concise given the complexity.

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

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

For a calculation tool with six parameters and no output schema, the description covers the essential context: what is computed, how it's computed (full recalculation), the key caveat about CDHR, and legal sources. It implies the output is a monetary gain, which is adequate for a single-value tool. It could mention the exact output format but that's a minor omission.

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

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

Schema description coverage is 100%, so all parameters are already documented in the schema. The description adds minimal extra meaning about parameters: it mentions the RFR is reduced and hints at CDHR relevance, but it doesn't significantly deepen the understanding of each parameter beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description explicitly states the tool computes the total tax gain from a deductible PER payment as Δ(IR + CEHR + CDHR), with a clear verb ('Gain') and resource ('versement PER'). It distinguishes itself from siblings by emphasizing a full recalculation rather than a simple marginal-rate multiplication, and it names the taxes involved, making its scope unambiguous.

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

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

The description provides clear guidance on when to use the tool: whenever the total tax saving of a PER contribution is needed, and it explicitly warns against using marginal tax rate times contribution ('jamais TMI × versement'), implicitly steering away from simpler tools like fiscal_tmi. It doesn't name sibling tools directly but the caution effectively differentiates it. A minor gap is not explicitly listing alternatives, but the guidance is sufficient.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context: the exact calculation rules, PASS reference years, and the express limitation. It doesn't contradict annotations and enriches understanding of how the tool behaves mathematically.

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

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

The description is a single dense paragraph but well-structured: purpose, salarié formula, TNS/BNC formula, and limitations, with legal sources. It front-loads the core purpose and packs useful data without redundancy. It could be split into bullet points for readability, but it's appropriately sized for the complexity.

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

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

For a calculation tool with no output schema, the description covers the essential calculation rules, PASS values, legal references, and exclusions. It doesn't explicitly state the return value (the ceiling amount), but that is implied. Given the complexity, it is sufficiently complete for correct invocation, though a note on edge cases (e.g., zero income) would make it fully complete.

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

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

Schema coverage is 100%, but the description goes beyond by explaining the meaning of tns (true/false) and how it affects the formula, including the 15% tranche between 1 and 8 PASS. It also gives concrete PASS values and the salary/TNS distinction, which helps the agent correctly map inputs to the intended regime.

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

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

The description clearly states the tool computes the annual PER deduction ceiling, with explicit formulas for salarié and TNS/BNC regimes. It distinguishes itself from siblings like fiscal_per_gain by specifying it handles the annual ceiling and is the 'express' version excluding reliquats and mutualisation, making its purpose unambiguous.

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

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

The description provides clear context: it explains it's for a single income, without reliquats or spousal mutualisation, implicitly telling the agent when NOT to use it. However, it doesn't name alternative tools (e.g., fiscal_per_gain for gains), so it lacks explicit routing to siblings, though the exclusion criteria are clear.

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

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

Beyond the readOnly/idempotent annotations, the description discloses the calculation sequence (IR + PS + surtaxe after abattements), the LMNP amortization reintegration, the output set (total, components, net seller), and managed exemptions. There is no contradiction with the annotations.

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

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

The description is dense and front-loaded with the core function, followed by rates, abattements, LMNP behavior, outputs, and legal sources. It is somewhat run-on, but each clause adds information and there is no filler.

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

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

For a 9-parameter calculator with no output schema, the description covers the calculation basis, exemptions, outputs, and legal references, giving an agent enough context to invoke it correctly. Nothing essential for selecting or calling the tool is missing.

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

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

The schema already documents all 9 parameters at 100% coverage, so the description carries little per-parameter burden. It adds useful context such as the '< 15 000 €' exemption threshold and the LMNP rule, but the parameter-level meaning is largely already present in the schema.

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

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

The description names the exact computation ('Impôt total sur la plus-value de cession d'un bien immobilier'), lists the rates (IR 19 %, PS 17,2 %, surtaxe), and states the outputs ('Rend l'impôt total, chaque composante et le net vendeur'). This makes it clearly distinguishable from siblings such as fiscal_surtaxe_pv_immobiliere, which cover only the surtax component.

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

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

It provides clear context: the tool applies to disposals outside the primary residence, after holding-period allowances, and it explicitly lists which exemptions are handled. It does not explicitly name alternative sibling tools or say when not to use it, 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 declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context by specifying the exact return format (a fraction 0-1 with unit RATE and a percentage field), which is crucial for correct interpretation, and clarifies the unit difference from tmi. It also cites legal sources, adding trustworthiness. This goes beyond annotations and is useful, though it doesn't cover edge cases like unknown income types.

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

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

The description is a single, dense sentence that front-loads the core purpose, then provides essential details on return format, unit distinction, and legal sources. Every phrase serves a purpose; there is no fluff or repetition. It is efficiently structured and easy to scan.

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

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

For a simple read-only lookup tool with one enumerated parameter and no output schema, the description is complete. It specifies the output shape (fraction and percentage), the units, the applicable rates, and the legal basis, and it clarifies the difference from the most closely related sibling. An agent can call this tool correctly with no missing information.

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%: the single parameter type_revenu has a full enum of 20 values and a description with examples. The tool description does not add parameter-specific details beyond what the schema already provides, so the baseline of 3 applies. The mention of rates depending on income type is implicit in the tool's purpose, not an elaboration on the parameter.

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

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

The description clearly states it returns the social contribution rate (taux de prélèvements sociaux) by nature of capital income, specifies the two possible rates (17.2% or 18.6%), and explicitly distinguishes it from fiscal_tmi by unit semantics. The verb 'renvoie' and the resource are specific, and the mention of tmi differentiates it from a key 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?

The description explicitly says 'à distinguer de tmi qui renvoie des points de pourcentage (unit PERCENT, 0-100)', telling the agent when to use this tool (for social contribution rates on capital income) versus fiscal_tmi (for income tax marginal rates). It does not mention other siblings like fiscal_flat_tax_vs_bareme, but the main confusion is addressed, making the usage context clear but not exhaustive.

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 and idempotentHint=true, so the tool is safe and non-mutating. The description adds context about the progressive tax schedule and the threshold, which are not captured by the annotations. It does not contradict the annotations and provides useful behavioral details beyond the structured metadata.

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

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

The description is a single, concise sentence that front-loads the tool's purpose, includes the key threshold, and cites the legal source. There is no wasted text or redundancy; it is efficiently structured.

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

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

Given the tool's simplicity (one parameter, no output schema, no nested objects), the description covers the essential information: what it computes, the threshold, and the progressive nature. However, it does not explicitly state the return value (e.g., the surtax amount in euros) or behavior for values below €50,000. Since there is no output schema, a brief mention of the return format would improve completeness, but it is not critical for this simple calculator.

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 only parameter, 'plus_value', is fully described in the schema ('Plus-value nette imposable (€)') with a minimum of 0, giving 100% schema description coverage. The description does not add any additional semantic detail about the parameter itself beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description clearly states the tool's function: it computes the surtax on real estate capital gains (surtaxe sur les plus-values immobilières), specifies the threshold of €50,000, and mentions the progressive rate schedule (barème par tranches). It also cites the legal source (CGI art. 1609 nonies G). This distinguishes it from the sibling tool fiscal_plus_value_immobiliere, which likely handles the base tax.

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 the usage condition by stating the €50,000 threshold and that it is an 'additional tax' (taxe additionnelle), but it does not explicitly mention when to use this tool versus the sibling fiscal_plus_value_immobiliere or any other alternative. There is no direct 'when not to use' or comparison to other tools, so the guidance is implicit 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 declare readOnlyHint and idempotentHint. The description adds valuable behavioral details: the return unit (PERCENT, e.g., 30 = 30%) and the inclusion of the family quotient cap, plus legal sources. This goes beyond the annotations, though it does not describe error handling or edge cases.

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 three sentences, front-loaded with the tool's name and purpose, followed by the unit clarification and a sibling distinction. Every sentence earns its place with no redundant information.

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

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

For a simple tool with three well-documented parameters and no output schema, the description covers the essential aspects: what it returns, the unit, the calculation context, and a key sibling distinction. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so all parameters are documented in the schema. The description does not add parameter-specific meaning beyond what the schema provides, so it meets the baseline but does not exceed it.

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

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

The description clearly states the tool returns the marginal tax rate (TMI) for the household based on the 2026 scale, accounting for the family quotient cap. It also distinguishes itself from the sibling tool prelevements_sociaux by specifying the unit (percentage points vs. fraction), making its purpose unambiguous.

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

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

The description explicitly tells the agent to distinguish this tool from prelevements_sociaux, which returns a fraction, providing a clear when-not scenario. It implies usage when TMI is needed, though it does not exhaustively compare against all siblings, but the context is sufficient.

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

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

Annotations already mark the tool as read-only and idempotent. The description adds useful context: it performs no calculation and cites source files. However, it does not describe the return structure or failure behavior, so it only partially supplements the annotations.

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

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

The description is compact and front-loaded: core purpose first, then the critical 'Ne calcule rien', then source references. Every sentence contributes and there is no redundant 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 zero-parameter, read-only planning map, the description adequately covers purpose, usage timing, and data provenance. The output format is not specified, but the intended use is clear enough for an agent 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?

The tool has zero parameters, so the baseline is 4. The description appropriately notes it calculates nothing, and there are no parameter meanings to clarify beyond the schema.

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

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

The description clearly identifies the tool as a capabilities/planning map for the Qotien engine, specifying what it exposes (what the engine can do and its reliability by domain). It also distinguishes itself from calculation siblings by explicitly stating 'Ne calcule rien'.

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

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

The description gives explicit timing: call it BEFORE choosing another tool, for planning and deciding when to hedge. It implies it should not be used for calculations, though it does not name a specific 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?

Les annotations indiquent déjà readOnlyHint=true et idempotentHint=true, et la description ajoute des informations comportementales utiles : le résultat est un résumé par clé (valeur, libellé, fiabilité), pas le détail complet, et la source est versionnée (references_officielles.json v0.8.6). Cela va au-delà de ce que les annotations fournissent.

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

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

La description est courte, va à l'essentiel et place l'action en tête. Chaque élément apporte une information utile : action, filtres, type de retour, alternative et source. Aucun mot superflu.

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

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

Pour un outil de recherche simple avec deux paramètres optionnels, aucune sortie structurée et des annotations couvrant la sécurité, la description est suffisante : elle précise le contenu du résumé, le nom de l'outil alternatif pour les détails et la version de la source. L'agent dispose de tout le nécessaire pour appeler ou non l'outil.

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

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

La couverture du schéma est de 100 %, donc le schéma documente déjà q et domaine. La description répète l'idée de recherche par mot-clé et de filtre par domaine, sans apporter de détails supplémentaires sur les formats ou comportements. Le baseline 3 est donc approprié, avec une légère perte car la mention « fiscal/retraite » omet la valeur successor présente dans l'enum du schéma.

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

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

La description identifie clairement l'action (lister des clés publiques), la ressource (le référentiel), les filtres disponibles (domaine, mot-clé) et le type de résultat (résumé par clé). Elle distingue explicitement l'outil de referentiel_valeur, ce qui lève toute ambiguïté entre les deux outils.

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

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

La description indique clairement quand utiliser cet outil (recherche/liste de clés publiques avec résumé) et redirige explicitement vers referentiel_valeur lorsque le détail sourcé complet est nécessaire. L'alternative est nommée et le critère de choix est précis.

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 and idempotent behavior; the description adds that the result is never a bare number and will include primary source, legal reference, verification date, and reliability level, plus the backing source version. This meaningfully characterizes the response 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?

Two short clauses front-load the core behavior and then specify the return guarantees; the source-file version note is useful provenance without bloat. There is no filler beyond a harmless title-like opening.

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

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

For a single-parameter read-only lookup with no output schema, the description covers the main output fields (source, legal reference, verification date, reliability) and notes the fixed 2026 scope. It does not state error/unknown-key behavior or how to obtain other years, but this is a minor gap for such a simple tool.

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

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

With 100% schema description coverage, the schema fully documents 'cle', including examples and how to obtain it via referentiel_recherche. The description only restates 'clé publique stable', adding no new parameter semantics beyond what the schema already provides.

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

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

The description clearly identifies the tool as returning the 2026 value of a fiscal or retirement constant by stable public key, with provenance fields. It is semantically distinguishable from sibling tools like referentiel_recherche and referentiel_versions, but 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?

It conveys a clear use context: call when you already have a stable public key and need the sourced, dated value rather than a raw number. It does not explicitly list exclusion cases or name alternative tools, so it stops short of full routing guidance.

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

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

Annotations already carry readOnlyHint=true and idempotentHint=true, so the safety profile is established. The description adds valuable context beyond that by enumerating exactly what the tool reveals — version history, cadence, next review date, and reliability levels — and even cites the underlying source file. No contradiction with annotations.

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

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

A single front-loaded sentence that leads with the core purpose, uses em dashes to enumerate content compactly, and closes with a concrete use case. The parenthetical source citation adds provenance without bloat. Every element earns its place.

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

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

For a zero-parameter metadata tool with no output schema, the description fully carries the burden of explaining return content. It lists the information categories an agent can expect — current vintage, history, cadence, next global review, reliability levels — which is complete for someone deciding whether this tool answers a freshness question.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is nothing to document, and the description sensibly spends no space on parameters.

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

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

The description states a specific purpose: it provides version and freshness metadata for the referentiel (current vintage, version history, cadence, next global review, reliability levels). It clearly differentiates itself from the sibling tools referentiel_recherche and referentiel_valeur, which query actual values, whereas this tool reports on the data's provenance and currency.

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 closing clause 'pour savoir de quand datent les valeurs et quand elles seront re-vérifiées' gives an explicit use case for when to invoke this tool. It doesn't name alternatives or exclusions explicitly, but the purpose is distinct enough from the value/recherche siblings that an agent can infer when to call it. Lacks an explicit 'use X instead' 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 declare readOnlyHint and idempotentHint, and the description adds substantial behavioral context: it returns an approximate result with a confidence level, reconstructs the career, applies SAM/PASS/decote assumptions, and discloses sources and the 2026 PASS value. It explicitly disclaims certainty, which is critical for correct agent interpretation.

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

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

The description is front-loaded with the core purpose and is dense, not bloated. The parenthetical source list adds transparency but makes the text slightly heavy; overall, every sentence earns its place.

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

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

Given seven parameters and no output schema, the description covers the operational essentials: input assumptions, output shape, accuracy caveat, and underlying sources. It could be more explicit about which sibling tool to use when full career data is available, but the current text is sufficient 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 coverage is 100%, so the baseline is 3. The description adds useful meaning by naming the driving inputs and explaining how they combine: reconstructed career, SAM capped at PASS, décote, and the source regimes. Optional parameters are not discussed, but they are already fully documented in the schema.

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

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

The description clearly states a specific action: estimate a pension from partial data using statut, revenu, âge, and âge de départ, and lists what it returns (central point, range, confidence level). It distinguishes itself from exact pension calculations by emphasizing it is an approximation that replaces a missing RIS, not a certain calculation.

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 usage context: use this tool when career data is partial or the RIS is missing, and explicitly warns it is not a certain calculation and not a substitute for a real career record. It does not name specific sibling tools as alternatives, but the boundary is clearly drawn.

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, covering the safety profile. The description adds genuine behavioral value beyond annotations: 'PAS de total sommé (les leviers ne s'additionnent pas naïvement)' discloses the deliberate non-summing behavior, and 'Chaque montant porte sa confiance et sa source' explains the confidence/source attribution per figure. This is useful context that annotations do not provide. No contradiction with the annotations.

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

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

The description is a dense, single run-on block of text with heavy em-dash and semicolon use. It front-loads the purpose well, but the legal citations (CSS articles, Circulaire CNAV 2026-04, Service-Public references) are appended as a large tail that adds bulk. It is information-rich and every element arguably earns its place, but the lack of sentence structuring hurts readability.

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

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

This is a high-complexity tool (17 parameters, aggregating 7+ levers) with no output schema, so the description must carry the return-value burden. It does explain the output conceptually (ranked menu with gain/ROI/confiance/sources, no summed total) and the legal grounding. The precise output structure is not fully specified, but for the complexity involved the description covers the key aspects an agent needs.

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 76% — moderately high. Four parameters (parts, trimestres_acquis, trimestres_requis, pension_complementaire_annuelle) lack schema descriptions, and the tool description does not compensate for these. However, the schema itself carries strong semantics, notably the tmi warning about fraction vs. percentage and the activation conditions ('active les gains chiffrés'). The description adds little parameter-level meaning beyond what the schema provides, warranting the baseline 3.

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

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

The description states a specific verb ('renvoie') and resource ('le MENU CLASSÉ des leviers d'optimisation retraite'), enumerating the exact levers covered (rachat de trimestres, surcote parentale, retraite progressive, âge de départ, cumul emploi-retraite, optimisation du SAM, PER). It clearly distinguishes itself from the sibling lever-specific tools (retraite_rachat, retraite_surcote_parentale, retraite_progressive) by being the aggregated ranking view rather than a single-lever calculator.

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 — it takes a full situation (âge, trimestres, SAM, statut, enfants) and returns a ranked menu — which suggests it is the overview tool versus the granular siblings. However, it never explicitly states 'use this for a comprehensive comparison; use retraite_rachat for detailed single-lever analysis' or provides any when-not conditions. The routing to siblings is left to inference.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so this is clearly a safe read/compute operation. The description adds valuable behavioral detail beyond annotations: the exact formula, the décote coefficient behavior, coverage per regime family, and source references. It does not describe the output format/units, but the name and formula make the computed result reasonably inferable.

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 fairly long, but each part earns its place: purpose, formula, scope list, routing to the sibling, and source traceability. The core formula and routing are front-loaded; the source citations at the end are extra but not harmful. It could be slightly tighter, but it is well-structured and readable.

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

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

Given the tool's complexity (6 params, no output schema), the description provides enough context for an agent to compute the pension and route between regimes. The main gap is that it does not explicitly state whether the returned value is an annual amount, monthly amount, or in euros, though the formula and 'pension brute' wording strongly imply an annual gross pension.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds extra semantic value by tying parameters together in the formula (traitement/salaire de référence × 75% × trimestres liquidables ÷ requis × décote), which clarifies how salaire_reference, trimestres_liquidables, and trimestres_requis interact beyond their individual schema entries.

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

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

The description names the exact resource ('Pension d'un régime en ANNUITÉS') and provides the full formula, distinguishing it from the points-based sibling retraite_pension_regime. It is specific about scope: fonction publique, régimes spéciaux, IEG-CNIEG.

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

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

The description explicitly says to use retraite_pension_regime for points-based regimes (Agirc-Arrco, complémentaires, bases CNAVPL), which directly routes the agent to the correct alternative. It also enumerates the covered regimes, leaving no ambiguity about when this tool applies.

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 include readOnlyHint=true and idempotentHint=true, so the safety profile is already declared. The description adds valuable context about the 'Contrôle de vraisemblance intégré (anti-erreur de sous-régime)' and references the golden-tested formulas, giving confidence in correctness. It doesn't describe error handling beyond the sanity check, but given annotations, this is sufficient.

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

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

The description is a single dense paragraph that fronts the key formula and coverage, then the routing instruction, then sources. It is information-rich but a bit heavy; however, every sentence adds value, and it remains focused.

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 moderate complexity (7 params, some contingent like trimestres_acquis only for CNAVPL), the description clearly states the formula, lists all covered regimes, and points to sources. It doesn't elaborate edge cases (e.g., age_depart behavior for each regime), but the schema covers the key defaults and the routing stops misuse. Output schema is absent, but the description is complete enough 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 coverage is 100%, with each parameter having a detailed description (e.g., age_legal defaults to 64, age_depart default implies no decote/majoration, trimestres_manquants applies to complementary salariés). The description adds the key formula (points × valeur de service 2026 × coefficient), but it does not explain how each parameter maps to the formula or edge cases. Baseline 3 is appropriate.

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

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

The description clearly states the tool computes gross pension for points-based regimes, enumerates covered regimes (Agirc-Arrco, Ircantec, RCI, RAFP, CNAVPL bases, etc.), and explicitly contrasts with annuity/SAM (CNAV) or traitement regimes that should use retraite_estimation. This distinguishes it from siblings and makes its scope unambiguous.

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

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

It explicitly instructs when to NOT use this tool ('Pour un régime en annuités/SAM (CNAV) ou en traitement (fonction publique), utiliser retraite_estimation.'), which is a clear exclusion and alternative routing. It also specifies coverage of 10 CNAVPL bases and complementary/ASV regimes, leaving no ambiguity about applicability.

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

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

The description goes well beyond the read-only annotation by disclosing internal calculations: it 'splitte base/complémentaire', 'applique la couche brut→net (1 % maladie sur la seule part complémentaire)', and 'Chaque jambe est vraisemblance-vérifiée ; la confiance globale suit la jambe la plus faible'. This gives the agent a precise model of the tool's processing and confidence semantics, with no contradiction to annotations.

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

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

The description is one dense but logically ordered paragraph: purpose → mechanics → exclusion → confidence → sources. Each clause contributes unique operational information, though it could be broken into bullets for effortless scanning. At around 100 words it remains information-dense without 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 complex multi-parameter tool with no output schema alone, the description covers input semantics, the transformation pipeline, the excluded non-points regimes, and the confidence model. It does not explicitly state the return value shape (e.g., totals, split values, confidence field), but the behavioral details partially compensate. Overall, an agent has enough to select and invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds semantic nuance by clarifying that 'regimes' must be 'EN POINTS' and enumerating the scope (base CNAVPL + tous les complémentaires/ASV), and by explicitly connecting 'pensions_fournies' to non-points regimes (CNAV, fonction publique). This exceeds the schema's generic field descriptions, earning a 4.

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 'Pension totale consolidée (multi-régimes, le détail du RIS)' and details the operation: 'Somme les régimes EN POINTS d'un relevé... splitte base/complémentaire, applique la couche brut→net'. This clearly distinguishes it from sibling single-regime tools and estimation tools by naming a specific verb, resource, and scope.

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

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

It explicitly instructs supplying non-points regimes via 'pensions_fournies (issues de retraite_estimation ou du RIS) pour un total réellement total', naming both the target parameter and the producing siblings. It also implies the gross-proxy behavior without RFR by mentioning 'Sinon le total brut sert de proxy' (though that exact phrasing is in the schema, the description's context reinforces it). A direct 'when not to use for a single regime' statement is absent, but the multi-régimes scope makes the intent clear.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true, and the description does not contradict them. It adds useful behavioral context: the tool computes a fraction of pension, continues acquiring rights, and applies changed eligibility rules after 01/09/2025. This goes beyond what the annotations alone 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?

The description is a single dense paragraph with the key mechanism and conditions front-loaded. The legal article references and source list add verifiability but also length; the core functional information could be more compact without losing value. Still, no sentence is purely 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 tool with 10 parameters and no output schema, the description covers eligibility, the fraction formula, and statut-specific rules, which is substantial. However, it never explains what the tool returns, how optional parameters like rfr and parts affect the calculation, or how the result should be interpreted. There is enough information for basic use but a noticeable gap remains for a complex legal calculator.

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 80%, so the baseline is 3. The description adds real value by explaining the formula, linking statut to quotité ranges (salarié 40–80%, fonction publique 50–90%, TNS 20–60% via diminution_revenus), and reinforcing the 150-trimestres requirement. However, it does not clarify the role of rfr or parts, which remain opaque.

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

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

The description clearly identifies a progressive-retirement calculator—'Retraite progressive (fraction de pension + temps partiel)'—and states the core computation: Fraction = 100% − quotité travaillée. It also distinguishes itself from sibling retirement tools by focusing specifically on the fractional pension with part-time work, though it lacks an explicit imperative verb like 'calcule'.

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

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

The description provides meaningful eligibility context: accessible from age 60 since 01/09/2025, requiring 150 trimestres, with statut-specific quotité ranges. However, it does not explicitly tell the agent when to choose this tool over alternatives such as retraite_estimation or retraite_optimisation, leaving the comparison implicit.

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

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

Annotations already declare readOnlyHint and idempotentHint, covering safety and repeatability. The description adds valuable context about the calculation method (specific rates, 1% on complementary pension) and the version (barème 2026, RFR 2024), and legal sources. It does not contradict annotations and discloses the estimation fallback for missing RFR only in the schema, not here, but the added detail is substantial.

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

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

The description is dense but well-organized: it leads with the purpose, then lists components, outputs, version, and sources. Every sentence carries information, though the legal citations add length. It is appropriately structured and not redundant.

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 calculator with clear inputs and no output schema, the description covers the main aspects: what it computes, how it computes (rates and components), and what it returns. Edge cases like missing RFR are handled in the schema. The description is sufficiently complete for an agent to understand the tool's function and output, though it could benefit from a brief note on the estimation behavior.

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

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

Schema coverage is 100%, with each parameter having a description. The tool description adds no extra meaning beyond what the schema provides, such as the interpolation of thresholds for parts or the proxy behavior for missing RFR. It does not need to repeat, but also does not enhance the schema's parameter semantics.

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

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

The description clearly states it computes social contributions on a pension, converting gross to net, and lists the specific components (CSG, CRDS, CASA, 1% maladie) and outputs (net pension, CSG bracket, effective rate). It is specific to pensions, distinguishing it from general social contribution tools by its focus, though it does not name a 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?

The description implies its usage (for pension social contributions) but does not explicitly state when to use it versus alternatives like fiscal_prelevements_sociaux or retraite_pension_totale. It provides no exclusions or comparison with siblings, relying on the name and content to convey applicability.

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 and idempotentHint=true, so the description builds on that by adding key constraints: max 12 trimestres, abattement ≤40 for études, stage at 12% PMSS, and the two option modes. It clarifies the deductibility and ROI calculation. It doesn't contradict the annotations and provides useful behavioral context beyond the structured hints.

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

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

The description is a single dense paragraph, but it is well-organized: it starts with the main purpose, then details the computation basis, options, legal limits, and sources. Every sentence carries meaningful information. Though lengthy, the complexity of the domain justifies the size, and it is front-loaded with the core purpose.

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

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

Without an output schema, the description names the key outputs (coût, gain, ROI) and covers legal thresholds and sources. It does not specify the exact response structure but gives enough for an agent to know what to expect. Combined with the schema-validated parameters, it is reasonably complete for a tool of this complexity.

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

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

The description adds critical parameter context: it explicitly warns that tmi must be a fraction (0-1) and not a percentage (contrasting with the sibling tool fiscal_tmi), explains the two option values, and states the legal maximum trimestres. This goes beyond the schema's terse descriptions and helps the agent avoid common pitfalls.

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

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

The description clearly identifies the tool's purpose: computing the cost and profitability of buying retirement quarters (rachat de trimestres). It specifies the legal article (L351-14-1), names the two options (taux seul / taux et durée), and the outputs (coût, gain, ROI). It distinguishes itself from sibling tools like retraite_estimation or retraite_optimisation by focusing on the buyback scenario, making it unambiguous what this tool does.

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 for rachat de trimestres (buyback) but does not explicitly state when to prefer this tool over alternatives such as retraite_estimation or retraite_optimisation. It describes the domain and constraints but lacks explicit 'use this when' or 'use alternative X when' guidance, leaving the agent to infer based on the topic.

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 mark this read-only and idempotent. On top of that, the description adds useful behavioral context: it returns specific fields, can be filtered by family, and cites the unique source file and the fixed count of 47 caisses. No contradiction with annotations.

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

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

The description is compact and front-loaded with the main action, then the returned fields, then the data sources. It contains useful detail without padding, though a few field names like 'machine' and 'étage' remain terse.

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

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

For a simple read-only discovery tool with no required parameters and no output schema, the description is sufficient: it enumerates the returned fields, states the source and cardinality, and indicates the optional filter. A more explicit statement of the unfiltered default would be nice, but the schema already marks the parameter optional.

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%: the optional famille parameter is already fully documented in the input schema, including its enum values. The description only repeats 'Filtrable par famille' without adding new semantic meaning, so the baseline of 3 applies.

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

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

The description states a specific action and resource: it lists the point-based retirement regimes and says it returns them for discovery. It also distinguishes itself from sibling tools by explicitly tying the result set to what is calculable via retraite_pension_regime.

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 'Découverte' label and the phrase 'calculables via retraite_pension_regime' give clear context: this is the discovery/list tool for point-based regimes. It does not explicitly say when not to use it, but the intended role is clear without leaving it to inference.

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

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

Beyond readOnlyHint and idempotentHint, it discloses the exact rate, the cap at 4 quarters/5%, eligibility conditions, and that it handles the LFSS 2026 freeze. It does not describe the return format or behavior when eligibility fails, but annotations already cover safety.

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

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

The description is dense but front-loaded with the formula and cap, followed by conditions and legal sources. Legal citations add useful authority but slightly lengthen it; still, each sentence contributes significant 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 an 11-parameter tool with no output schema, the description covers formula, eligibility, and LFSS 2026 handling, but it does not specify the return value/format or the role of fiscal parameters such as rfr and parts. Some param semantics are left to the schema, so the description is adequate but not fully complete.

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

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

The description gives meaning to key parameters: the 1.25% per quarter in the window maps to trimestres_cotises_fenetre, 'gain en €' relates to pension_brute_annuelle, and the MDA condition ties to mda_parentale and nb_enfants. However, parameters like rfr, parts, age, trimestres_acquis, and trimestres_requis are not explained, leaving a gap at 55% schema 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?

The description clearly states that the tool computes the 'surcote parentale' pension increase for parents at full-rate one year before legal age, with formula and cap. It does not explicitly contrast itself with sibling retraite_* tools, but the specific term and legal reference make its purpose distinct.

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

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

It provides explicit eligibility conditions: legal age >= 63, required duration reached, and at least one MDA quarter, so an agent can decide when this tool applies. It does not name alternatives or exclusions, but the stated conditions are clear context.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the crucial caveat 'Résultat ESTIMÉ' and specifies that hypotheses (rendement/durée) are provided by the caller, and cites the calculation method. This enriches behavioral transparency beyond the annotations without contradiction.

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

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

The description is front-loaded with the title and purpose, then lists the strategies and outputs. It is a single paragraph with a clear structure, but it includes some redundancy (repeating the title) and could be slightly more concise. Still, every sentence adds value, so it is appropriately sized.

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

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

Given the absence of an output schema, the description explicitly states what the tool returns: 'Rend l'effort mensuel et le patrimoine/flux de trésorerie à terme de chaque stratégie.' It also notes the estimation nature and the source of assumptions, covering the essential context an agent needs to call it correctly. No missing critical information.

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 parameters are already described. The description adds semantic mapping by naming the three strategies ('tout apporter', 'apport minimal + placement d'un bien secondaire', 'apport minimal + placement financier') which correspond to the nested objects (unique, secondaire, financier). This helps the agent understand which object to populate for each strategy, going beyond the terse schema text.

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

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

The description clearly states the tool compares three financing strategies for a real estate project, naming each strategy explicitly. It uses a specific verb 'Compare' and identifies the resource (financing of a real estate project), and it is distinct from sibling tools like simulateurs_scpi or fiscal_*.

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 context: it is for comparing financing options for a real estate project. It does not name alternatives or provide explicit when-not guidance, but the scope is clear enough that an agent would know when to select it among the many simulateurs_* 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=true and idempotentHint=true, and the description adds valuable behavioral context: 'Résultat ESTIMÉ' (estimated result), the no-income-during-demembrement nature, full-ownership recovery at term, and the dependency on Qotien's cIR for tax. These go beyond the structured data and set correct expectations.

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

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

The description is dense but front-loaded with the core purpose and key behaviors, followed by a useful result caveat and sources. The parenthetical source list adds length but each component adds value. It is appropriately sized for the tool's complexity.

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

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

For a 7-parameter tool with no output schema, the description explains the modeling logic adequately but does not mention the output format or return value shape. An agent might wonder what exactly the projection returns. The 'ESTIMÉ' caveat helps, but a bit more on the output would improve completeness.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters. The description adds the general context that market assumptions are supplied by the caller and that tax is linked to cIR, but it does not detail specific parameters or their interactions beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Projette') and resource ('investissement en nue-propriété de SCPI... et l'usufruit correspondant'), making the core purpose clear. It does not explicitly name sibling alternatives, but the term 'démembrement' and the detailed scope distinguish it from the sibling simulateurs_scpi and simulateurs_scpi_credit.

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 through the description of the simulation scenarios, but there is no explicit when-to-use or when-not-to-use guidance relative to sibling tools like simulateurs_scpi. The mention of caller-provided market assumptions gives some context, but no exclusions or alternatives are 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 establish readOnlyHint=true and idempotentHint=true, so the description's job is lighter. It adds useful behavioral context: the result is ESTIMÉ, it depends on the rétrocession rate supplied by the caller, and it references the legal source (CGI art. 199 undecies B). This goes beyond the annotations without contradicting them.

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

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

The description is compact and front-loaded with the tool's purpose, followed by output specifics and a caveat. The source citation at the end is a minor extra but provides context for the legal basis; the structure earns a 4 rather than 5 because the title is partly repeated and the long parenthetical run-on could be slightly cleaner.

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 enumerate the main computed values, which is essential. It also conveys estimation uncertainty and legal grounding. It does not spell out return formatting or edge cases, but for a 6-parameter estimation tool with full schema documentation and safe read-only/idempotent annotations, the coverage is reasonably complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds only modest parameter insight, such as linking revenu_net_imposable to the cIR and noting that the rétrocession rate is caller-supplied, but it does not materially explain individual parameters beyond the schema's own 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?

The description opens with 'Estime la réduction d'impôt d'un investissement Girardin industriel' and then lists the exact outputs: impôt de référence, montant remboursé, and montant maximal investissable. The tool's specific object — Girardin industriel — distinguishes it clearly from the many fiscal_* and simulateurs_* siblings.

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

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

The description makes clear when the tool applies: estimating the one-shot tax reduction for a Girardin industriel investment, with the caveat that the result depends on the provided rétrocession rate. It does not explicitly name alternatives or exclusions, but the unique tax niche and the reference to the cIR de Qotien give sufficient context for an agent to route to it.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description does not contradict them. It adds valuable context by labeling the result as 'ESTIMÉ' and noting the theoretical schedule and default échéancier, plus the methodology (courbe en J, XIRR). This goes beyond the annotations to set expectations about the nature of the output.

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

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

The description is a single, dense paragraph with no wasted filler, but it repeats the title phrase 'Private Equity — échéancier appels/distributions (courbe en J)' at the start, which is redundant. It is structured with semicolons and flows well, but could be tightened. Overall it is efficient and front-loaded with the key verb and 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 a read-only simulator with three well-documented parameters and no output schema, the description covers the essential purpose, the default schedule, the outputs, and the estimation caveat. It does not explain the exact calculation logic or return format, but that is not required given the absence of an output schema. The description is sufficient for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents each parameter (multiple, date_debut, montant_initial) clearly. The tool description does not add parameter-specific meaning beyond what the schema provides; it only references outputs, not how inputs map. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Projette') and a precise resource ('un fonds de Private Equity sur un échéancier type (8 appels de capital puis 10 distributions)'), and lists concrete outputs (total appelé, total distribué, DPI/TVPI, TRI/XIRR). This clearly distinguishes it from sibling tools covering fiscal, retraite, or other simulateurs (SCPI, etc.).

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 by stating it projects a Private Equity fund, so an agent can infer when to use it. However, it does not explicitly mention alternatives or provide when-not-to-use guidance. Among siblings, the context is clear enough for a specialized simulator, but explicit exclusion or alternative naming is absent.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful context by stating 'Résultat ESTIMÉ' and citing the standard financial method (TRI/XIRR vs CAGR) and that assumptions are caller-provided. This goes beyond the annotations and clarifies the nature of the output.

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 about three sentences and front-loads the core purpose. It repeats the title but uses a dash to integrate it. It is efficient and free of fluff, though slightly verbose in explaining the TRI/CAGR distinction. Overall well-structured for quick reading.

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 read-only, idempotent annotations and the 100% parameter schema coverage, the description is mostly complete. It specifies the returned value (true TRI) and the estimation nature. However, it does not describe the exact output format (e.g., whether only a number or an object with additional fields), but for a calculator tool this is a minor gap.

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

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

Schema description coverage is 100% (each parameter has a French description). The description adds no parameter-specific details beyond what the schema already provides, such as 'versements programmés' which is implied by the parameter names. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description clearly states the verb 'Calcule' and the resource 'rentabilité d'un placement à versements programmés', and explicitly distinguishes the true TRI (weighted by timing) from CAGR. It also specifies the returned value is the true TRI, making the purpose unambiguous and differentiating it from simple CAGR calculations.

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

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

The description provides no guidance on when to use this tool versus sibling simulators (e.g., simulateurs_scpi, simulateurs_private_equity). It does not mention alternatives, exclusions, or prerequisites. An agent would have to infer that it applies to general scheduled-payment investments, but no explicit routing is given.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable context beyond that: it explicitly states 'Résultat ESTIMÉ' (a quality caveat), notes the life-expectancy bound (60–80), and cites legal/source references (CGI art. 158-6, INSEE table). These enrich the behavioral understanding without contradicting annotations.

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

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

The description is a single, dense sentence that front-loads the core purpose and then details the computation steps. Every clause earns its place: it covers inputs, outputs, estimation caveat, and sources without redundancy. The parenthetical source list is compact and useful.

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 estimator with no output schema, the description is complete: it lists all computed outputs (rente brute, part imposable, surcoût d'IR, rente nette mensuelle), states the input scope (age 60–80, capital, fiscal parameters), and flags that results are estimates. It also references the underlying legal/statistical sources, giving an agent confidence in the tool's domain. No critical information is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining how parameters feed into the calculation: e.g., 'part imposable selon l'âge d'entrée en jouissance' and 'via le cIR de Qotien' clarify the role of revenu_net_imposable and parts. This extra context helps an agent understand the tax logic, though it does not describe formatting or units for any parameter.

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

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

The description names a precise verb ('Estime') and resource ('rente viagère servie contre l'aliénation d'un capital'), and enumerates the computed components (rente brute, part imposable, surcoût d'IR, rente nette). This clearly distinguishes it from fiscal and retraite siblings, which focus on taxes or pension income rather than annuity estimation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any sibling tools, conditions for use, or exclusions. An agent would have to infer suitability purely from the tool name and description, which is insufficient for correct 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 mark this as read-only and idempotent, and the description adds valuable context: the result is ESTIMÉ, non garanti, and depends on caller-provided assumptions for yield, revaluation, and taxation. It also cites the financial method used, which helps an agent set expectations beyond the annotation hints.

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

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

The description is well structured: it front-loads the resource and outputs, then adds the estimation caveat and sources. It is slightly longer than strictly necessary because it repeats the title phrase 'SCPI au comptant — projection à terme', but each clause still contributes meaningful 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 compensates by naming the key outputs and the estimation nature, which is sufficient for a read-only projection tool. It could have explicitly noted the monthly payment parameter, since 'au comptant' might misleadingly suggest lump-sum only, but the schema covers that detail.

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

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

Schema description coverage is 100%, so the schema fully documents all 8 parameters. The description only summarizes hypothesis categories (rendement, revalorisation, fiscalité) without adding details beyond the schema, which matches the baseline of 3.

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

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

The description uses a specific verb ('Projette') and resource ('investissement en SCPI au comptant') and lists concrete outputs: valeur brute/nette de revente, revenus distribués, TRI. The phrase 'au comptant' also differentiates it from siblings like simulateurs_scpi_credit and simulateurs_demembrement_scpi.

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 'au comptant' framing gives clear context: this tool is for cash SCPI investment projections, not credit or démembrement variants. However, it does not explicitly name alternative tools or state when-not-to-use conditions, so it stops short of full exclusion guidance.

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

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

Annotations already mark the tool as read-only and idempotent. The description adds meaningful context beyond that: the result is an ESTIMATE based on yield/revaluation/rate assumptions, market assumptions are caller-provided, and interest plus insurance are deductible. No contradiction with the annotations.

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

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

The description is compact, front-loaded with the scenario and outputs, and includes the essential estimation caveat and methodology source. There is minor redundancy with the annotation title, but the description remains dense and readable.

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

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

For a simulation tool with no output schema, the description covers the key outputs, the estimation caveat, and the calculation basis. It does not detail the return structure, but the schema documents all inputs and the tool's purpose is clear enough 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 100%, so the input schema already explains every parameter. The description only refers generically to assumptions about yield, revaluation, and rates, adding no specific parameter-level meaning beyond what the schema provides.

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

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

The description uses the verb 'Projette' with a clear resource ('une SCPI financée à crédit') and enumerates the computed outputs: mensualité, effort d'épargne, fonds propres, and TRI. The 'à crédit' qualifier clearly distinguishes this tool from sibling SCPI simulators such as simulateurs_scpi and simulateurs_apport_credit.

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

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

The intended use case is clear: projecting a SCPI purchase financed by a loan, including deductible interest and insurance. It does not explicitly name sibling tools or state when not to use them, so it falls just short of full alternative routing.

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