Skip to main content
Glama

gentry.fr, le logement en France

Encadrement des loyers d'une commune

encadrement_des_loyers
Read-onlyIdempotent

Dit si une commune applique l'encadrement des loyers, et lequel des trois régimes : loyer libre, évolution encadrée (décret zones tendues, le loyer ne peut pas dépasser celui du locataire précédent à la relocation) ou loyers plafonnés (loi ELAN, un plafond en euros par mètre carré). Rend le barème en vigueur quand la commune en publie un. À utiliser pour toute question sur le montant légal d'un loyer, la relocation, ou le préavis réduit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
communeYesNom de commune, adresse ou code INSEE : « Lille », « 75118 »

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already mark it read-only, idempotent, and non-destructive, so the description's job is to add behavioral nuance. It explains the conditional output—which regime applies, and that the barème is returned only 'quand la commune en publie un'—plus the legal detail of the relocation cap. This goes well beyond the annotation fields.

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

Conciseness5/5

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

Three dense sentences: the first states the core purpose, the second explains the regimes, the third gives the barème condition and use cases. No filler, and the most important information is front-loaded.

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

Completeness5/5

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

With no output schema, the description carries the burden of describing the return: whether the commune is covered, which of the three regimes applies, and the applicable barème when published. It is sufficient for an agent to invoke the tool correctly with the single commune parameter.

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

Parameters3/5

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

Schema description coverage is 100% for the single 'commune' parameter, including examples of accepted formats. The description adds no new parameter-level detail, so the baseline of 3 is appropriate.

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?

The description uses a specific verb ('Dit si') and resource ('une commune applique l'encadrement des loyers'), then enumerates the three distinct regimes and the barème output. This clearly separates it from sibling tools like classement_taxe_fonciere or fiche_commune through its rent-control scope.

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?

The closing sentence explicitly states when to use it: 'pour toute question sur le montant légal d'un loyer, la relocation, ou le préavis réduit.' It gives clear context but does not explicitly name alternatives or exclusions, so it stops short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources