Parcellaire — cadastre, DVF & DPE

Détails d'une parcelle cadastrale

get_parcelle

Read-onlyIdempotent

Retourne la fiche de base d'une parcelle cadastrale à partir de son IDU (14 caractères) : surface, adresse, commune. Tout le reste est à demander via 'include', uniquement pour les sections utiles à la question (chaque section allonge la réponse) : parcelles adjacentes (parcelles_adjacentes : celles qui la touchent, avec surface, bâti et nombre de DPE ; pour toute question de voisinage ou quand l'adresse ou un DPE pointe une petite parcelle sans bâti), bâtiments (batiments), transactions immobilières (dvf), diagnostics énergétiques (dpes), zonage d'urbanisme (urbanisme, la plus lente), données bâtiment BDNB (bdnb), piscines, copropriétés (rnc), personnes morales et droits déclarés, dont propriétaire ou syndic (majic_pm), permis de construire (sitadel). La réponse donne toujours le nombre d'éléments de chaque section (donnees_disponibles), même non demandée : s'en servir pour décider quelles sections lire.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "parcelle_id": "<parcelle_id>"
    },
    "name": "get_parcelle"
  }
}

Input Schema

Name	Required	Description
`include`	No	Sections à inclure, ex: ['dvf', 'dpes']. Aucune par défaut : sans include, seule la fiche de base de la parcelle est retournée.
`max_items`	No	Nombre maximum d'éléments par section liste (défaut 30). Les sections tronquées sont signalées dans 'sections_tronquees'.
`parcelle_id`	Yes	IDU de la parcelle, 14 caractères, ex: '33063000IK0001'

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 2, 2026

changedInput schema / properties / include / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "items": {
-          "enum": [
-            "batiments",
-            "dvf",
-            "dpes",
-            "urbanisme",
-            "bdnb",
-            "piscines",
-            "rnc",
-            "majic_pm",
-            "sitadel"
-          ],
-          "type": "string"
-        },
-        "type": "array"
-      },
-      {
-        "const": "",
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "anyOf": [
+      {
+        "items": {
+          "enum": [
+            "parcelles_adjacentes",
+            "batiments",
+            "dvf",
+            "dpes",
+            "urbanisme",
+            "bdnb",
+            "piscines",
+            "rnc",
+            "majic_pm",
+            "sitadel"
+          ],
+          "type": "string"
+        },
+        "type": "array"
+      },
+      {
+        "const": "",
+        "type": "string"
+      }
+    ]
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / include / description

Previous value: -"Sections à inclure. Défaut: ['batiments', 'dvf', 'dpes']"New value: +"Sections à inclure, ex: ['dvf', 'dpes']. Aucune par défaut : sans include, seule la fiche de base de la parcelle est retournée."

Changed1 schema field changedSep 25, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```

Changed7 schema fields changedSep 25, 2026

addedInput schema / properties / include / anyOf

Added value: +[
+  {
+    "anyOf": [
+      {
+        "items": {
+          "enum": [
+            "batiments",
+            "dvf",
+            "dpes",
+            "urbanisme",
+            "bdnb",
+            "piscines",
+            "rnc",
+            "majic_pm",
+            "sitadel"
+          ],
+          "type": "string"
+        },
+        "type": "array"
+      },
+      {
+        "const": "",
+        "type": "string"
+      }
+    ]
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / include / items

Removed value: -{
-  "enum": [
-    "batiments",
-    "dvf",
-    "dpes",
-    "urbanisme",
-    "bdnb",
-    "piscines",
-    "rnc",
-    "majic_pm",
-    "sitadel"
-  ],
-  "type": "string"
-}

removedInput schema / properties / include / type
```
Removed value: -"array"
```

addedInput schema / properties / max_items / anyOf

Added value: +[
+  {
+    "anyOf": [
+      {
+        "maximum": 200,
+        "minimum": 1,
+        "type": "integer"
+      },
+      {
+        "const": "",
+        "type": "string"
+      }
+    ]
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / max_items / maximum
```
Removed value: -200
```
removedInput schema / properties / max_items / minimum
```
Removed value: -1
```
removedInput schema / properties / max_items / type
```
Removed value: -"integer"
```

First observedSep 25, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover the read-only, idempotent, non-destructive profile. The description adds genuinely non-structured behavior: every section inflates the response, urbanisme is the slowest call, and donnees_disponibles always reports per-section counts even when not requested, so the agent can decide what to fetch.

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?

Front-loaded with the core behavior, then the include semantics and the fallback rule. It is a single dense paragraph that reads as a run-on, but nearly every clause carries usable information rather than filler.

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 still explains the return shape: base fiche fields plus always-present donnees_disponibles counts and truncation signaling. Defaults (no include, max_items default) are consistent between description and schema, leaving nothing an agent needs missing.

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 100%, so the baseline is 3, but the description goes beyond by decoding the opaque enum values (dvf = transactions immobilières, rnc = copropriétés, sitadel = permis de construire, etc.) which the schema lists without meaning. It leaves 'piscines' and 'max_items' behavior to the schema, so not a 5.

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 and resource ('Retourne la fiche de base d'une parcelle cadastrale') plus the key identifier (IDU, 14 caractères) and the base fields returned. This clearly distinguishes it from search_parcelles (which finds parcelles) and get_parcelle_context.

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?

Explicitly says include should only be used for sections useful to the question and that each section lengthens the response, and gives a concrete trigger for parcelles_adjacentes ('pour toute question de voisinage...'). No explicit routing versus the near sibling get_parcelle_context, which keeps it from a 5.

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

All Parcellaire — cadastre, DVF & DPE tools Inspect

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

Need Help?