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.