Skip to main content
Glama
Sign In

Infoparcelle - cadastre, DVF, DPE, PLU

by fr.infoparcelle
OverviewDiscussionsAdmin

infoparcelle_plu_search

Read-onlyIdempotent

📜 Rechercher des zones PLU (Plans Locaux d'Urbanisme) avec leurs documents associés.

Fonction: Accéder aux règles d'urbanisme applicables sur un territoire.

Qu'est-ce qu'un PLU? Le Plan Local d'Urbanisme (PLU) est un document d'urbanisme qui définit:

  • Les règles de construction et d'aménagement

  • Les zones constructibles et leurs destinations

  • Les coefficients d'occupation des sols

  • Les servitudes d'utilité publique

  • Les documents graphiques et réglementaires

Zones PLU principales:

  • U (Urbaine): Zone urbanisée, généralement constructible

  • AU (À Urbaniser): Zone future d'urbanisation

  • A (Agricole): Zone agricole protégée

  • N (Naturelle): Zone naturelle et forestière protégée

Structure des données retournées:

Chaque zone PLU contient les champs suivants :

  • titre (string): Nom de la zone PLU. Ex: "Zone UBa - Habitat dense"

  • description (string): Description textuelle de la zone et ses règles

  • zone (string): Code de zone principal. Ex: "U", "AU", "A", "N"

  • type_zone (string): Sous-type de zone précis. Ex: "UBa", "AUs", "U1e"

  • surface (number): Surface de la zone en m²

  • perimetre (number): Périmètre de la zone en mètres

  • documents (object): ⚠️ STRUCTURE COMPLEXE - Contient les documents officiels du PLU:

    • partition (string): ID unique du PLU. Ex: "DU_75056"

    • fichiers (array): Tableau de fichiers PDF catégorisés. Chaque fichier contient:

      • code (string): Code du document

      • titre (string): Titre du document. Ex: "Règlement zone UBa"

      • nom_fichier (string): Nom du fichier PDF. Ex: "75056_reglement_UBa_2024.pdf"

      • url (string): URL HTTPS du PDF. Ex: "https://../doc.pdf"

      • categorie (string): Catégorie du document. 6 catégories possibles:

        • "Documents Règlementaires" - Textes réglementaires de la zone

        • "PADD" - Plan d'Aménagement et Développement Durable

        • "OAP" - Orientations d'Aménagement et Programmation

        • "Documents Graphiques" - Plans et cartes

        • "Annexes" - Documents complémentaires

        • "Avis de l'État" - Avis des administrations

      • date_creation (string): Date de création au format YYYY-MM-DD

  • parcelles (array): Liste des parcelles concernées (max 10). Chaque parcelle contient:

    • cadastre_id (string): Identifiant cadastral

    • superficie (number): Surface en m²

  • municipalite (object): Commune concernée:

    • code (string): Code INSEE. Ex: "75056"

    • nom (string): Nom de la commune. Ex: "Paris"

  • centre (object): Coordonnées GPS du centre de la zone (Point GeoJSON)

  • contour (object): Géométrie complète de la zone (Polygon GeoJSON)

  • bbox (array): Boîte englobante [minX, minY, maxX, maxY]

Cas d'usage:

  • Vérifier les droits à construire sur une parcelle

  • Consulter le règlement d'urbanisme applicable

  • Identifier les zones constructibles d'une commune

  • Télécharger les documents PDF officiels (règlement, OAP, PADD)

  • Analyser les destinations autorisées (habitation, commerce, etc.)

Exemples:

  1. Zone PLU d'une parcelle: { code_parcelle: "75056000AB0001" }

  2. Toutes les zones urbaines d'une commune: { code_municipalite: "75056", zone: "U" }

  3. Zone PLU à des coordonnées GPS: { lat: 48.8566, lon: 2.3522 }

  4. Zones d'un type précis: { code_postal: "75008", type_zone: "UBa" }

Conseils:

  • Les documents PLU sont essentiels pour tout projet immobilier

  • Consultez toujours le règlement de zone avant d'acheter

  • Les zones U sont généralement les plus constructibles

  • geometrie='contour' vous donne les limites exactes de la zone

  • Le champ 'documents.fichiers' contient les URLs des PDF à télécharger

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "infoparcelle_plu_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
latNoLatitude (WGS84)
lonNoLongitude (WGS84)
zoneNoZone PLU: A, Ah, AUc, AUs, N, Nd, Nh, U
champsNoChamps souhaités. Valeurs possibles: titre, description, zone, type_zone, surface, perimetre, documents, parcelles, municipalite, bbox, centre, contour
formatNoFormatjson
limiteNoRésultats/page
curseurNoCurseur pagination
champ_triNoChamp de tri
geometrieNoType géométriecentre
ordre_triNoDirection triasc
type_zoneNoType précis: UBa, AUs, U1e, etc.
code_postalNoCode postal (5 chiffres)
code_sectionNoCode section cadastrale
code_parcelleNoCode parcelle cadastrale
code_municipaliteNoCode INSEE commune (5 car)

Output Schema

NameRequiredDescriptionDefault
donneesYes
paginationNoPagination a curseur.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered and the description adds only that parcelles are capped at 10 and that documents.fichiers carries the PDF URLs. It says nothing about pagination behaviour (curseur/limite interplay), whether filters combine with AND or OR, or what an empty filter set returns. Most of the bulk is return-field documentation that the existing output schema already provides.

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

Conciseness2/5

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

The purpose is correctly front-loaded, but roughly two thirds of the text is a field-by-field enumeration of the response (titre, description, zone, documents.fichiers.categorie, etc.) that duplicates the output schema verbatim. Generic purchase advice ('Consultez toujours le règlement de zone avant d'acheter') does not help an agent invoke the tool and inflates the definition substantially.

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

Completeness3/5

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

The tool is complex — 15 parameters, all optional — and an output schema already exists, so the return-value recitation is redundant while the genuinely hard questions go unanswered: what happens with zero filters, how pagination and sorting are meant to be driven, and how the geographic and cadastral filters interact. Adequate to start a call, but not sufficient to call it well.

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 description coverage is 100%, so the baseline is 3, but the examples go beyond the schema by showing which parameters are meant to be combined — code_parcelle alone, code_municipalite + zone, lat/lon, code_postal + type_zone — and the tips clarify the practical effect of geometrie='contour'. It still does not say whether these filters are mutually exclusive, OR-ed, or which ones are required.

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 opening line states a specific verb and resource ('Rechercher des zones PLU ... avec leurs documents associés') and immediately frames the purpose as accessing applicable urbanism rules. The resource is clearly distinct from every sibling (parcelle, DPE, DVF, copropriétés, permis), so an agent can route to it without opening the schema.

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 'Cas d'usage' block and the four worked examples give concrete selection contexts (rights-to-build check, downloading regulation PDFs, identifying constructible zones). What is missing is any explicit negative guidance or naming of an alternative sibling — e.g. that parcel-level lookups belong to infoparcelle_parcelle_get — and nothing explains which of the 15 optional parameters must be combined for a valid query.

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

All Infoparcelle - cadastre, DVF, DPE, PLU 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