Skip to main content
Glama

dynamique_immobiliere

Read-onlyIdempotent

Dynamique immobilière et potentiel de croissance d'une zone (point + rayon). Combine 3 sources officielles : permis de construire (Sit@del/SDES, maille COMMUNE — logements autorisés/commencés récents → habitants attendus), zones AU du PLU (Géoportail de l'Urbanisme/IGN — futurs quartiers réservés, géolocalisés), ventes de terrains à bâtir (DGFiP DVF, géolocalisées). Sortie en 2 registres : 'note' = VOLUME (logements autorisés/commencés, nombre et immédiateté des zones AU) destiné au scoring de potentiel ; 'info' = quartiers concernés (nommés), habitants attendus, prix indicatifs (contexte, hors score). En ville dense les permis-commune sont grossiers → s'appuyer sur zones AU + terrains (géolocalisés). Point côtier/isolé sans commune au géocodage inverse → couverture.permis='indisponible:commune_introuvable' et meta.code_commune=null, MAIS zones AU + terrains restent servis (calcul par rayon) — l'outil ne plante jamais pour ça. Paris/Lyon/Marseille : Sit@del ne descend pas à l'arrondissement → les permis servis sont ceux de la VILLE ENTIÈRE (meta.code_commune_permis, ex 75056), couverture.permis='partiel:ville_entiere_plm' et le signal ne s'appuie alors que sur les zones AU. Commune absente de Sit@del, ou sans aucune année pleine → couverture.permis='indisponible:no_data' (les zéros ne sont PAS une donnée ; info.permis.annee_en_cours peut malgré tout être servi pour une commune nouvelle). Les totaux permis ne somment que des ANNÉES PLEINES (info.permis.annees_pleines) ; l'année en cours, incomplète (le SDES publie avec ~2 mois de retard), est servie à part dans info.permis.annee_en_cours avec ses mois_couverts — ne JAMAIS la comparer telle quelle à une année pleine ni l'ajouter aux totaux. Moins de 5 années pleines en base → 'partiel:fenetre_courte' ; une année de la fenêtre à moins de 12 mois publiés → 'partiel:annees_incompletes' (total SERVI mais non comparable, non scoré dans les deux cas). 'geojson' = polygones des zones AU pour la carte. Sources : SDES, IGN/GPU, DGFiP.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latYesLatitude du centre (WGS84).
lonYesLongitude du centre (WGS84).
rayon_kmNoRayon en km (0.1-10, défaut 3).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
infoNoContexte non-scorable : habitants_attendus, permis { annees_pleines, annee_en_cours: { annee, mois_couverts, logements_autorises, logements_commences } | null }, quartiers_au (libellés), prix_m2_median, terrains. Ne PAS intégrer à une note d'attractivité.
noteNoDonnées de VOLUME — à utiliser pour le scoring LLM. logements_autorises_recent, logements_commences_recent, zones_au_nombre, zones_au_immediates, signal.
geojsonNoFeatureCollection GeoJSON des polygones des zones AU (pour la carte).
couvertureYesStatut de dégradation par section : 'ok' | 'partiel:<raison>' | 'indisponible:<raison>'. Un 'partiel:' signifie que le chiffre est SERVI mais NON comparable et NON scoré ('partiel:ville_entiere_plm' = chiffre de la ville entière ; 'partiel:fenetre_courte' = moins de 5 années pleines ; 'partiel:annees_incompletes' = une année de la fenêtre a moins de 12 mois publiés ; 'partiel:lignes_illisibles'). Lire avant d'interpréter note/info.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedOutput schema / properties / couverture / description
      Previous value: -"Statut de dégradation par section : 'ok' | 'indisponible:<raison>'. Lire avant d'interpréter note/info."New value: +"Statut de dégradation par section : 'ok' | 'partiel:<raison>' | 'indisponible:<raison>'. Un 'partiel:' signifie que le chiffre est SERVI mais NON comparable et NON scoré ('partiel:ville_entiere_plm' = chiffre de la ville entière ; 'partiel:fenetre_courte' = moins de 5 années pleines ; 'partiel:annees_incompletes' = une année de la fenêtre a moins de 12 mois publiés ; 'partiel:lignes_illisibles'). Lire avant d'interpréter note/info."
    • changedOutput schema / properties / info / description
      Previous value: -"Contexte non-scorable : habitants_attendus, quartiers_au (libellés), prix_m2_median, terrains. Ne PAS intégrer à une note d'attractivité."New value: +"Contexte non-scorable : habitants_attendus, permis { annees_pleines, annee_en_cours: { annee, mois_couverts, logements_autorises, logements_commences } | null }, quartiers_au (libellés), prix_m2_median, terrains. Ne PAS intégrer à une note d'attractivité."
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Very rich behavioral disclosure beyond readOnly/idempotent hints: exact coverage statuses ('indisponible:commune_introuvable', 'partiel:ville_entiere_plm'), guarantee that it never crashes on missing commune, the 'zeros are not data' rule, partial-year incomparability, and no-data vs current-year distinctions.

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

Conciseness4/5

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

The description is long and dense, but for a tool with this many data-quality edge cases nearly every sentence earns its place. It is front-loaded with the high-level purpose and then layers caveats logically, though the formatting is a single heavy paragraph and could be better structured.

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?

Given the output schema already defines the return structure, the description need not restate it. It covers the relevant edge cases, fallbacks, coverage semantics, comparisons to avoid, and source provenance, making it complete enough for correct invocation and interpretation.

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?

Input schema coverage is 100%, so the parameters are already fully documented. The description reinforces that the tool works on a point + radius and that the radius is used for fallback computation, but it does not add substantial parameter-level meaning beyond the 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?

The description opens with a precise purpose: real-estate dynamics and growth potential of a zone defined by point + radius, combining three official sources. It describes the two output registers ('note' for scoring volume, 'info' for context), which clearly differentiates it from the health-related sibling tools.

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 description gives concrete context-dependent guidance: in dense cities prefer AU zones and land plots because commune-level permits are coarse; coastal/isolated points still get AU/terrain data; Paris/Lyon/Marseille get city-wide permits only. It does not explicitly name sibling tools to use instead, so it stops short of a 5, but the decision context is clear.

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.