french-rental-compliance

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

Even though readOnlyHint=true already communicates safety, the description adds behavioral details beyond annotations: it returns an end date calculated 'de quantième à quantième' from receipt date, returns required justificatifs, auto-resolves zone tendue from insee_code/commune, and explicitly states it is a deterministic legal formula with no AI. It also clarifies the reception-date meaning, which is a potential misuse trap.

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 two information-dense sentences with no fluff. It front-loads the core purpose and then packs the essential legal logic, output, and determinism note. Every clause contributes necessary meaning for correct selection and 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 complex tool with 7 parameters, no output schema, and no nested objects, the description is remarkably complete. It covers the legal basis, decision branches, input dependencies, return content (end date and justificatifs), geographic scope, and determinism. Combined with full schema descriptions and readOnly annotation, an agent has enough 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?

While the schema covers 100% of parameters with descriptions, the tool description adds meaningful semantic integration: it explains how lease_type drives the base period, how insee_code/commune resolve zone tendue, how ground_id maps to statutory grounds under art. 15 I, and that reception_date is the receipt date. This goes well beyond the individual 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 uses a specific verb+resource ('Computes the tenant's notice period for terminating a French residential lease'), and immediately adds the key legal formula (furnished vs unfurnished, reduced conditions). This clearly distinguishes it from sibling tools like check_zone_tendue or check_dpe_rental_restrictions, which perform different checks.

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 this tool is relevant (notice period calculation in France métropolitaine) and sets exclusions ('France métropolitaine rules'). It implicitly differentiates from siblings by focusing on notice period rather than DPE or zone-tendue alone, though it does not explicitly name alternative tools or state 'use this instead of X'.

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 declare readOnlyHint=true, and the description reinforces this with 'Deterministic rules from official thresholds — no AI involved.' It adds specific behavioral context: exact legal citations, dates (2025, 2028, 2034, 25 Aug 2022), and the 10-year validity rule with transitional details. This goes beyond the annotations, providing confidence in predictability and covering the conditional behavior when dpe_issue_date is supplied.

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 and front-loads the core purpose. Each sentence adds essential information: what the tool returns, specific thresholds, and the deterministic nature. It is slightly dense but appropriately detailed for a tool with legal rules; no 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 no output schema, the description sufficiently enumerates the return values (letting ban status/date, rent freeze, DPE validity) and their conditions. It also provides the legal context and geographic scope. It is complete enough for an agent to understand the tool's capabilities and constraints, though a explicit return structure would be even clearer.

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 covers both parameters with descriptions and enum, but the description enriches dpe_issue_date by explaining its exact role ('whether the DPE itself is still valid (10-year rule + the 2013–2021 transitional expiries)'). It also implicitly clarifies that dpe_class is the primary input. This value-add justifies a score above 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 clearly states 'returns the French rental restrictions in force' given a DPE class, naming the specific verb ('returns'), resource ('rental restrictions'), and input ('dpe_class'). It enumerates exact outputs (ban status/date, rent freeze, validity) and distinguishes itself from siblings (calculate_tenant_notice_period and check_zone_tendue) by focusing on DPE-based rental rules.

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 tells when to use it: 'Given a dwelling's DPE class... returns...' which is a clear trigger condition. It does not explicitly contrast with alternatives, but the unique scope (DPE rental restrictions) makes the use case obvious. No exclusions are needed for such a specialized tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the bar is lower. The description adds substantial behavioral context beyond annotations: it is a 'deterministic dataset lookup on DILA reference data — no AI involved.' This discloses the underlying data source and non-AI nature, which is valuable for expectations. 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 a single compact paragraph but is well-structured: purpose first, then the critical nuance, then the data source, then input instructions. Every sentence carries unique information; no filler or repetition. It is appropriately sized for the complexity of the tool.

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

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

The tool has 3 parameters, no output schema, and annotations are present. The description covers the purpose, the two perimeters, the data source, and input requirements. It does not explicitly state the return format (e.g., boolean or which list), but the description's emphasis on 'which one' strongly implies the output will include the applicable perimeter. Given the lack of an output schema, a brief mention of the response would have made it complete, so one point is deducted.

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%, but the description adds essential relational semantics: 'Provide insee_code, or commune (+ code_postal to disambiguate).' This explains the priority of insee_code and the role of code_postal for homonym disambiguation—information not present in the schema's individual parameter descriptions. This is a clear added value.

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 'Checks whether a French commune is in the zone tendue perimeter' and crucially distinguishes between the two lists (décret n° 2013-392 vs TLV tax perimeter). This is a specific verb+resource+scope that far exceeds a simple restatement and effectively sets it apart from the sibling tools (tenant notice, DPE restrictions).

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 explicit input guidance: 'Provide insee_code, or commune (+ code_postal to disambiguate).' It also clarifies which perimeter matters for the reduced notice vs fiscal measures, implicitly telling the user when this tool's distinction is critical. However, it does not explicitly name sibling tools or state when not to use this tool, so it falls short of a perfect score.

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