Skip to main content
Glama

french-rental-compliance

by com.adminlanding
OverviewDiscussionsAdmin

French rent revision calculator (IRL indexation)

calculate_rent_revision
Read-only

New rent after the yearly IRL revision; no revision for class F/G homes. · Nouveau loyer après la révision IRL annuelle ; pas de révision pour les logements classés F ou G. — Computes the legally revised rent for a French residential lease using the INSEE IRL (indice de référence des loyers): new rent = current rent × (IRL of the lease's reference quarter ÷ IRL of the SAME quarter one year earlier), loi n° 89-462 art. 17-1. The reference quarter (trimestre de référence IRL) is the one written in the lease — pass it as reference_quarter. Two legal limits: the landlord must ask for the revision within ONE YEAR of the date it takes effect (the date agreed in the lease or, failing that, the end of each year of the lease), otherwise the landlord is deemed to have waived it for the year gone by (art. 17-1, I, al. 3) — when revision_date is more than one year old the result says so; and the revision cannot be applied in a dwelling of DPE class F or G (art. 17-1, III; leases concluded, renewed or tacitly continued since 24 August 2022 — loi n° 2021-1104 du 22 août 2021, art. 159) — pass dpe_class to get that check. The revised rent applies from the landlord's request, never retroactively (art. 17-1, I, al. 4). Deterministic INSEE data + fixed formula — no AI. France métropolitaine.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dpe_classNoDwelling's DPE class, if known — in a class F or G dwelling the revision cannot be applied (art. 17-1, III).
current_rentYesCurrent monthly rent excluding charges (hors charges), in euros.
revision_dateNoDate the revision takes effect, as an ISO date (e.g. 2026-09-01) — normally the lease anniversary; accept a natural date from the user and format it yourself. When given, the reference quarter is taken in THIS year; if reference_quarter names a different year, the result carries a warning and this date wins.
reference_quarterYesThe IRL reference quarter OF THE YEAR OF THE REVISION (e.g. '2026-T2' for a revision in 2026). The lease usually names the quarter only ('T2', '2e trimestre') — infer the year from the revision date, or pass revision_date and give just the quarter here. Accepts '2026-T2', 'T2 2026', 'Q2 2026', or 'T2' when revision_date is provided. Never the quarter of the previous year: the tool itself divides by the same quarter one year earlier.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / dpe_class / description
      Previous value: -"Dwelling's DPE class, if known — F or G blocks the revision (rent freeze)."New value: +"Dwelling's DPE class, if known — in a class F or G dwelling the revision cannot be applied (art. 17-1, III)."
  2. Changed2 schema fields changed
    • changedInput schema / properties / reference_quarter / description
      Previous value: -"The IRL reference quarter named in the lease (trimestre de référence). Accepts forms like '2026-T2', 'T2 2026', 'Q2 2026'."New value: +"The IRL reference quarter OF THE YEAR OF THE REVISION (e.g. '2026-T2' for a revision in 2026). The lease usually names the quarter only ('T2', '2e trimestre') — infer the year from the revision date, or pass revision_date and give just the quarter here. Accepts '2026-T2', 'T2 2026', 'Q2 2026', or 'T2' when revision_date is provided. Never the quarter of the previous year: the tool itself divides by the same quarter one year earlier."
    • addedInput schema / properties / revision_date
      Added value: +{
+  "description": "Date the revision takes effect, as an ISO date (e.g. 2026-09-01) — normally the lease anniversary; accept a natural date from the user and format it yourself. When given, the reference quarter is taken in THIS year; if reference_quarter names a different year, the result carries a warning and this date wins.",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}
  3. Changed1 schema field changed
    • removedInput schema / additionalProperties
      Removed value: -false
  4. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only cover read-only/local execution, yet the description goes well beyond them: it discloses the one-year waiver rule that produces a warning when revision_date is over a year old, the non-retroactive application of the new rent, the F/G exclusion, and that the output is deterministic INSEE data with no AI. This is exactly the kind of behavioral context an agent needs for a legal calculation.

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

Conciseness3/5

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

The key result and the F/G exclusion are front-loaded, which is good, but the opening line is duplicated in French and English, and the body is dense with repeated legal citations (loi n° 89-462, loi n° 2021-1104). It is informative but verbose for a tool description.

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

Completeness4/5

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

For a 4-parameter tool with no output schema, the description is nearly complete: it enumerates the returned value (new rent) and the warning conditions, and covers the two legal limits. It is slightly thin on the exact shape of the result, but an agent has enough to call and interpret it correctly.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains that reference_quarter names the quarter of the revision year and that revision_date wins if they disagree, plus the relationship between the two (a mismatch triggers a warning). Useful interpretation guidance on top of an already-documented schema.

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

Purpose5/5

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

States a specific verb+resource (computes the legally revised French residential rent) and gives the exact formula (IRL of reference quarter ÷ same quarter one year earlier), naming the governing statute. It implicitly distinguishes itself from siblings like check_dpe_rental_restrictions and generate_rent_receipt by being a calculation tool.

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

Usage Guidelines4/5

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

Clear context for when to use it: the yearly IRL revision, with the note that class F/G dwellings are excluded and that dpe_class enables that check. However, it never explicitly routes the agent to sibling tools (e.g. check_dpe_rental_restrictions) for the DPE question, leaving the boundary between overlapping tools to inference.

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

All french-rental-compliance toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources