Infoparcelle - cadastre, DVF, DPE, PLU

infoparcelle_geocoder_ban

Read-onlyIdempotent

🎯 Obtenir une adresse précise par son identifiant BAN.

Fonction: Récupérer les détails complets d'une adresse à partir de son identifiant unique BAN (Base Adresse Nationale).

Retourne:

Informations complètes de l'adresse
Coordonnées GPS exactes
Parcelles cadastrales associées
Toutes les métadonnées disponibles

Cas d'usage:

Obtenir les détails d'une adresse dont on connaît l'identifiant BAN
Récupérer les coordonnées GPS exactes d'une adresse
Vérifier les informations d'une adresse de référence
Accéder aux parcelles cadastrales d'une adresse connue

Note: L'identifiant BAN est généralement obtenu via une recherche préalable avec geocoder_search.

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": {
      "identifiant_ban": "<identifiant_ban>"
    },
    "name": "infoparcelle_geocoder_ban"
  }
}

Input Schema

Name	Required	Description	Default
`champs`	No	Liste des champs souhaités
`format`	No	Format de sortie	json
`identifiant_ban`	Yes	Identifiant unique BAN. Ex: '75056_8845_00007'

Output Schema

Name	Required	Description	Default
`donnees`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile needs no restating. The description adds real value on top: it discloses the dependency on a prior search to obtain the identifier and summarizes the payload (address details, exact GPS coordinates, cadastral parcels, metadata).

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 purpose and the return content are front-loaded, and the markdown sections make scanning easy. The 'Cas d'usage' bullets largely restate the same idea four ways, and the 'Retourne' block duplicates what the output schema already provides, adding mild redundancy.

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 single-record read with an output schema, the description covers what an agent needs: the lookup key, where to get it, and the shape of the result. It omits failure behavior for an unknown or malformed BAN identifier, which is a minor remaining gap given the annotations and schema already in place.

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 coverage is 100%, with identifiant_ban carrying a concrete example format ('75056_8845_00007') and format/champs documented in-schema. The description only implicitly touches the 'champs' selection through its 'Retourne' list and says nothing about the json/geojson switch or default behavior, so it does not meaningfully extend 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 first line states a specific verb and resource ('Obtenir une adresse précise par son identifiant BAN') and the prerequisite section makes clear this is a lookup-by-identifier, not a text search. That cleanly separates it from the sibling infoparcelle_geocoder_search without needing to open either 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 enumerates concrete situations (fetch GPS coordinates, verify a reference address, retrieve associated cadastral parcels) and the closing note routes the agent to geocoder_search when the BAN identifier is unknown. It stops short of explicit when-not conditions such as invalid/unknown IDs, but the alternative path is named.

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 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?