french-rental-compliance

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

The annotations already declare readOnlyHint=true, but the description goes well beyond structured data: it states the calculation is deterministic ('no AI, no assessment of any person or motif'), advances the applicable convention (IDCC 3239 verified on Légifrance 2026), and discloses the non-availability of rupture conventionnelle. This prevents misuse of a network tool as a legal judgment or open-ended approximation tool.

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

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

The description is front-loaded with the purpose and immediately names the sibling tool. The legal version is lengthy, but each segment adds a needed constraint or discloses an exclusion, and the French duplicate serves the bilingual domain. Overall it is longer than the bare minimum but well-structured and not redundant from an informational perspective.

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 legal calculator with 8 parameters and no output schema, the description is unusually complete: it covers scope, excluding modality, output-like elements (last Pajemploi declaration, docs and who receives/provides, contest window), legal formula, and alternative routing to the generic tool. An agent has all signs needed to choose the tool and understand the result shape.

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 baseline is 3, but the description adds meaningful legal and calculation context: it names the 1/80 rule based on gross salaries excluding entretien/repas/km, the 8/15-day/1-month notice thresholds under article 120, and the 9-month care condition. This helps the agent understand how params like am_total_gross_paid and start_date will drive the computation.

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 verb and resource: it calculates end-of-contract outcomes for an assistant maternel with a parent-employer (retrait d'enfant, démission, préavis, indemnité, Pajemploi documents). It also differentiates itself from the sibling generic tool by name: 'Same engine as calculate_home_employment_end_of_contract with regime pre-set to assistant_maternel.'

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 is explicit about when to use this tool versus alternatives: it names the generic sibling calculate_home_employment_end_of_contract, and explains that a 'garde d'enfant à domicile' should go to the generic tool with regime garde_domicile. It also excludes 'rupture conventionnelle NOT available', giving clear selection criteria.

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?

Though annotations already mark readOnlyHint true, the description adds substantial behavioral context: notice runs from the FIRST PRESENTATION, results are deterministic with no AI and no assessment of persons or motifs, and the same figures are returned whichever party calls. These details set correct expectations about the tool's limits and assumptions.

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 structured: it leads with purpose, then lists all legal topics in one high-information paragraph, and ends with verification and determinism notes. It is longer than average, and the bilingual opening repeats content, but the density is justified for a complex legal calculator and every sentence adds 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 highly complex legal computation with 14 parameters and no output schema, the description is unusually complete. It covers notice, indemnity, rupture conventionnelle restrictions, paid leave, CESU/Pajemploi declaration, contest window, beneficiary of documents, applicable law, and verification source. Important exclusions and behavioral constraints are also stated, leaving little ambiguity about what the agent should pose as inputs.

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 legal formulas behind the parameters: dismissal indemnity (considered 1/4 month per year, then 1/3, from the 8th month, best of 12/3-month average), assistant-maternel indemnity (1/80 gross from the 9th month), and the earliest entretien préalable date calculation. It does not explicitly walk through all 14 parameter names, but functionally links the formulas to the relevant inputs.

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 verb and resource: it calculates the end of a home-employment contract in France and enumerates the concrete deliverables: notice, dates, indemnity, and documents. It also narrows the scope to CCN 3239 and lists the relevant categories (cleaner, carer, garde d'enfant, assistant maternel), so it is easy to distinguish from salary, rent, and other calculators.

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

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

The description states clear applicable context: both parties, particular employer ↔ salaried employee, home employment under IDCC 3239, with specific mention that the general Code du travail dismissal procedure does not apply. It does not explicitly list alternatives in the prose, but the schema tells the user to use calculate_assistant_maternel_end_of_contract in one embedded paraphrase; the distinction is present in the tool definition.

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 the description aligns by indicating a calculation ('Converts') with no side effects. It adds value by detailing the output (annual + monthly net, deduction breakdown, data year) and emphasizing deterministic rules (no AI), which goes 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?

The description is efficient, with a clear lead sentence, a translated version, and a concise explanation of method and outputs. It is slightly verbose due to bilingual text but still well-organized and 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?

Given the complexity of Swiss payroll and no output schema, the description adequately explains the return format and the payroll components. It lacks edge-case details (e.g., salary caps) but is sufficient for an agent to understand scope and results.

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 covers 100% of parameters, so baseline is 3. The description enriches parameter meaning by listing the specific deductions (AVS/AI/APG, AC, LPP, NBU) and tying them to the canton, which clarifies how canton and age affect the calculation beyond the schema's brief statements.

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: converting a gross annual Swiss salary to net for cross-border workers, with a specific verb ('converts') and resource ('gross salary to net'). It distinguishes itself from siblings like rent or tenant tools by focusing on salary and cross-border context.

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 implicitly indicates usage for cross-border workers in specific cantons, and mentions deterministic rules, but does not explicitly state when to prefer this over alternatives or exclusions. Context is clear, but no direct when-not guidance.

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

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

Beyond the readOnlyHint annotation, the description discloses deterministic behavior ('Deterministic INSEE data + fixed formula — no AI'), the legal basis (loi n° 89-462 art. 17-1), and specific enforced limits (one-year forfeiture, DPE F/G freeze since 25 August 2022). This provides substantial operational transparency that annotations alone would not 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 front-loaded with a concise bilingual summary, then delivers the formula, legal limits, parameter guidance, and determinism note in a structured sequence. Every sentence carries necessary information with no filler — it is long but dense and well-organized.

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 (legal formula, multiple constraints, data source), the description covers all essential aspects: inputs, formula, legal limits, DPE freeze, geographic scope, and deterministic nature. No output schema exists, but the output is clearly implied as the new rent amount in euros. This is complete for an agent to select and 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 baseline is 3. The description adds meaningful context: it explains that reference_quarter comes from the lease, that dpe_class triggers the freeze check, and clarifies that current_rent is 'hors charges'. These clarifications reinforce the schema's descriptions and add legal purpose, but they don't add new syntax or format details 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 states the tool 'Computes the legally revised rent for a French residential lease using the INSEE IRL' with the exact formula. It distinguishes itself from sibling tools (e.g., Swiss salary calculator, DPE restriction checker) by specifying the French rent revision context and the specific legal 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 provides clear context for when to use the tool: for computing legally revised rent under French law, with special handling for the one-year claim limit and DPE F/G freeze. It explains when to pass dpe_class for the freeze check. However, it doesn't explicitly name alternative tools or state when not to use it, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces this by labeling the computation 'Deterministic legal formula — no AI involved.' It adds valuable behavioral context beyond annotations: the reception-date emphasis (never the sending date), the automatic zone-tendue resolution, and the return of justificatifs. This exceeds the baseline for tools 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 dense but well-organized, using a semicolon-separated enumeration and clear cause-effect statements. It front-loads the purpose and then provides necessary legal details. The bilingual intro is slightly redundant, but every sentence conveys essential information, keeping it appropriately concise 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?

With no output schema, the description must convey what the function returns, and it does: 'the end date computed ... plus which justificatifs must accompany the letter.' It also covers the legal grounding, the zone-tendue resolution, and the scope (France métropolitaine). It lacks explicit error-handling notes (e.g., what happens with invalid dates), but for a deterministic calculator the description is sufficiently 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 schema covers 100% of parameters, so the baseline is 3. The description adds significant semantic value: it explains how lease_type dictates the base period, how ground_id and zone_tendue interact to reduce it, and clarifies the crucial nuance of reception_date (landlord receives, not sent). This goes well beyond the schema's raw field 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 clearly states the tool computes the tenant's notice period for terminating a French residential lease, with specific rules (furnished = 1 month, unfurnished = 3 months with reductions). It names the legal reference (loi n° 89-462 art. 15) and distinguishes itself from sibling tools (e.g., calculate_rent_revision, check_zone_tendue) by its explicit scope and outputs (end date and justificatifs).

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 indicates when to use the tool: for calculating tenant notice periods in France métropolitaine, and even notes it automatically resolves zone tendue, avoiding the need for separate calls. However, it does not explicitly name alternative tools or state when NOT to use it (e.g., for other legal jurisdictions or other lease types), which would push it to 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 description goes beyond the readOnlyHint annotation by detailing the exact rules and thresholds: 'G banned since 2025, F from 2028, E from 2034', the rent freeze since 25 Aug 2022, and the 10-year validity rule with transitional expiries. It also assures 'Deterministic rules from official thresholds — no AI involved,' which sets expectations. This thoroughly aligns with the readOnlyHint and adds significant behavioral context.

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

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

The description is dense but every sentence carries specific information: the summary line, the detailed breakdown of each restriction, and the legal references. It front-loads the main purpose and then expands. It could be slightly trimmed, but given the complexity of the rules, the length is justified.

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 must explain what is returned, and it does: letting ban status and date, rent freeze, and DPE validity. It covers all three main aspects with precise dates and conditions, and notes the deterministic nature. For a tool with two parameters and clear rules, this is comprehensive.

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% for both parameters, so the schema already explains them. The description adds meaning by linking dpe_issue_date to the validity check ('when dpe_issue_date is provided — whether the DPE itself is still valid') and implicitly defines the DPE class range 'A–G'. It enriches the semantics without restating 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 the tool's purpose: it returns French rental restrictions (letting ban, rent freeze, DPE validity) based on a DPE class. The verb 'returns' and resource 'French rental restrictions' are specific, and it distinguishes itself from sibling tools that focus on Swiss salary, rent revision, etc., which are unrelated domains.

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 for when to use the tool: when a dwelling's DPE class is known and French rental restrictions are needed. It mentions France métropolitaine for the letting ban, and the optional dpe_issue_date for validity. It doesn't explicitly state alternatives, but siblings are obviously different topics, so no confusion arises. Could be improved by explicitly stating not to use for non-French properties.

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 openWorldHint=false. The description adds valuable behavioral context: it is a deterministic threshold rule, explicitly states 'no AI', and lists the exact return values (eligibility, share, threshold, data year). 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 key threshold, followed by user applicability and return values. It includes a redundant French duplicate of the opening phrase, which costs a little conciseness, but overall every major point is stated efficiently.

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

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

For a simple two-parameter deterministic calculator with no output schema, the description is complete: it states the rule, the eligibility criterion, the benefit, and the exact outputs. No additional context is needed to invoke or interpret the result.

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 swiss_income and total_income are already fully documented in the schema. The description adds conceptual framing (household worldwide income, taxable in Switzerland) but does not provide additional parameter-level detail 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 states the tool's purpose: it tells a Geneva cross-border worker whether they qualify as a quasi-resident. It names the specific verb/resource/scope and distinguishes itself from sibling tools like calculate_net_swiss_salary and check_zone_tendue.

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 clearly identifies the target user and context: Geneva cross-border workers considering itemised deductions. It does not explicitly name alternatives or state when not to use it, but the context is specific enough to guide selection.

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 readOnlyHint=true and openWorldHint=false annotations, the description adds valuable behavioral context: it is a 'deterministic dataset lookup on DILA reference data (service-public.fr simulator dataset) — no AI involved.' It also discloses the real-world consequences of each list, making the tool's behavior and semantic boundary much clearer.

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 information-dense and front-loaded with the core question, then the critical caveat about the two lists. There is minor redundancy from the bilingual repetition of the opening question, but overall every substantive piece of the explanation earns its place given 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?

Given the absence of an output schema, the description adequately conveys what the caller should expect conceptually: membership in the zone tendue perimeter and which list applies. It also covers the data source, determinism, and input disambiguation needs. It does not specify the exact output shape, but for a boolean/list lookup the semantic outcome is clear enough.

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% and the schema already explains the commune name, INSEE code preference, and postal-code disambiguation. The description essentially restates this guidance ('Provide insee_code, or commune (+ code_postal to disambiguate)') without adding new parameter-level meaning 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 uses a specific verb and resource: 'Checks whether a French commune is in the zone tendue perimeter' and immediately distinguishes the two lists (reduced notice vs. tax-only). This clearly separates the tool from sibling tools and makes its exact 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 gives clear usage context by explaining the critical distinction between the two 'zone tendue' lists and warns that the wider TLV perimeter is often mislabelled. It also tells the caller how to provide input ('Provide insee_code, or commune (+ code_postal to disambiguate)'), though it does not explicitly compare against sibling tools or state when not to use it.

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

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

Annotations already indicate readOnlyHint=true inferring a safe read operation. The description adds that it's 'Deterministic official allowance tables — no AI', which explains the computation nature. It also describes the return values (Swiss annual/monthly in CHF, CAF monthly in EUR, differential, year). It doesn't mention any side effects, but for a read-only deterministic calculator, this is adequate. It adds value beyond 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 sentences: first states the purpose and outputs, second adds deterministic nature and return specifics. Every word serves a purpose, no 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?

The tool has 3 parameters (all described in schema), no output schema, but the description explicitly lists the returned values (Swiss annual/monthly in CHF, CAF monthly in EUR, differential, data year). It also mentions the deterministic nature and the EU regulation. For a calculation tool with clear inputs, this is complete enough. Could have mentioned edge cases (e.g., max children, age limits) but schema covers those. Overall adequate.

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 parameters are well-documented in the schema. The description adds context about the differential top-up and spouse working in France, which matches the parameter. But it doesn't add significant meaning beyond the schema descriptions. 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 compares Swiss vs French family allowances for a frontalier, specifies the differential top-up, and lists the exact outputs. It uses a specific verb ('compares') and resource ('family allowances for a frontalier'), and it's distinct from siblings which deal with other legal/financial 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 implies usage for frontaliers with children comparing Swiss vs French allowances concrete. It doesn't explicitly mention when not to use it or alternatives, but the purpose is specific enough that it's clear this is for cross-border workers. Given the sibling tools are unrelated (net salary, rent revision, etc.), the context is sufficient. It could have explicitly stated 'use this if you are a frontalier with children' but it's 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 readOnlyHint annotation, the description discloses that the tool is deterministic (official premium/rate tables, no AI) and states the return value includes both monthly figures and the data year. This adds valuable behavioral context not covered by 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, information-dense sentence with clear structure (front-loaded with purpose, then details). The French repetition is redundant but not harmful. No filler words; every clause contributes to understanding the tool's function and outputs.

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 explains that returns monthly CAF figures for both options plus data year, and mentions age bands for dependants. It also notes deterministic tables, covering all key aspects. It does not explain the exact calculation, but that is not required for 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 coverage is 100%, so baseline is 3. The description adds meaning by explaining dependant pricing bands (0-18 child, 19-25 young adult, 26+ adult), which is not explicit in the schema. It also clarifies that the annual salary is in CHF and canton is a border canton, enhancing parameter understanding.

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 estimates monthly costs for two health-insurance options (LAMal vs CMU) for cross-border workers, with specific verbs and resource scope. It is distinct from all sibling tools which cover salary, rent, tenure, DPE, quasi-residence, zone tendue, and family allowances, so no confusion arises.

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 specifies the exact context: France–Switzerland cross-border workers with droit d'option, choosing between Swiss LAMal and French CMU/PUMa. It does not explicitly mention alternatives or when not to use, but the context is clear enough for an agent to select this tool over siblings.

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