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 the exact formula, the reference-quarter logic, the two enforced legal limits, deterministic INSEE data, and the no-AI guarantee. This gives a full behavioral model of the calculation and its constraints with no 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 dense yet organized: a front-loaded bilingual result statement, formula, then legal constraints, then determinism. Some bilingual duplication is present, but every substantive part earns its place for a tool with legal edge cases.

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 four parameters and no output schema, the description gives the formula, the two blocking conditions, the reference-quarter rule, and scope. It could explicitly state the return value shape, but the formula and 'new rent' framing make the output inferable.

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, and the description adds real value on top: it tells the agent to pass the lease's reference quarter as reference_quarter and explains that dpe_class enables the F/G freeze check. Some parameter detail remains schema-only (revision_date, current_rent), but the schema already documents them thoroughly.

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

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

The description names a specific verb ('computes'), a precise resource (legally revised rent for French residential lease via INSEE IRL), and gives the exact formula, making the tool unmistakable. Its scope ('France métropolitaine', F/G freeze) also separates it from the sibling 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?

It clearly defines when the tool is appropriate: yearly IRL revision of French residential leases, with the one-year claim limit and F/G freeze described. It never names sibling alternatives or says when not to use it, but the context is specific enough that an agent can infer 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 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?

Adds meaningful behavior beyond annotations: deterministic official rate tables with no AI, dependants priced by age bands, and returns both monthly figures, the data year, and transmission instructions. Aligns with readOnlyHint=true and openWorldHint=false 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?

Core content is dense and useful, but the opening bilingual phrase duplicates the title before the explanatory sentence begins. Slightly verbose; the first clause could be removed without losing 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?

No output schema exists, yet the description compensates by specifying the exact returns: both monthly figures, the data year, and how to transmit the signed choice form. All key inputs, pricing logic, and currencies are covered, providing a complete picture for an agent.

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 adds value by clarifying that CMU/PUMa is a percentage of income, that dependants are grouped into specific age bands, and that the salary context is annual Swiss CHF.

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

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

States the exact verb 'Estimates' and resource: monthly cost of the two health-insurance options for a France–Switzerland cross-border worker. Explicitly names LAMal vs CMU/PUMa, making it instantly distinguishable from sibling tools like compare_family_allowances.

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?

Clearly identifies when to use: when a France–Switzerland cross-border worker is choosing between LAMal and CMU/PUMa under the droit d'option. Does not explicitly name sibling alternatives or exclusion conditions, but the context is unambiguous enough for 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?

Annotations are all false, so the description carries the full behavioral burden. It discloses determinism ('not AI-generated content'), the French-only legal document plus optional non-binding English appendix, the 24-hour single-use link and deletion lifecycle, per-network caps and rate_limited response, and an instruction to have the landlord verify every field. This is exceptionally transparent.

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

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

The description is heavily padded with marketing and account-tier/pricing details ('€4.90 — one document... €49 — 50 documents...') and the bilingual headline duplicates the same 'free, no account' information. While the essential behavior is front-loaded, much of the length is not needed for correct tool invocation.

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

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

For a tool with no output schema, the description explains the core outcome: a French legal PDF, a 24-hour single-use link, deletion after 24 hours, and a structured rate_limited result. It also covers per-network caps and the landlord-verification step. The only gap is an exact description of the response envelope/field names, but the provided lifecycle and legality details make it 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?

Schema coverage is 100%, so the baseline is 3. The description loosely lists field groups (landlord, tenant, property, period, rent/charges, payment date) and clarifies includeEnglish's non-binding role, but the schema already documents every parameter, including locale and receipt-month derivation. No meaningful parameter semantics are added beyond that.

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

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

States it produces a 'Rent receipt (quittance de loyer, loi n° 89-462 art. 21) PDF' from user-supplied data, naming the specific resource and legal basis. This clearly distinguishes it from the sibling calculators/checkers, which solve numerical or eligibility questions rather than generating documents.

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

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

Provides rich context: free, no account needed, 24-hour single-use link, per-network caps, payment happening in the browser rather than through the agent, and 'not legal advice'. However, it never explicitly names an alternative tool or says when not to use it, so it reaches clear-context but not explicit exclusion.

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