Provides tools to geocode addresses, places (POI), and French cadastral parcels, and reverse geocode using the IGN Géoplateforme (French National Institute of Geographic and Forest Information) public API.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@geocodage-mcp geocode 10 rue de la Paix, Paris"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Serveur MCP (Model Context Protocol) connecté à l'API de géocodage de la Géoplateforme (IGN).
Permet de géocoder des adresses, lieux (POI) et parcelles cadastrales françaises en temps réel, ainsi que de faire du géocodage inverse.
API publique, sans clé. Limite : 50 requêtes/seconde par IP.
Sources : BAN (adresses), BD TOPO® (POI), Parcellaire Express PCI (parcelles).
Node.js >= 18
Related MCP server: Geocode BAN MCP
npm installnode index.jsLe serveur communique via stdio et est prêt à être connecté à un client MCP.
geocodeGéocodage direct via GET https://data.geopf.fr/geocodage/search.
Paramètres principaux :
Nom | Type | Requis | Description |
| string | oui | Chaîne à géocoder (adresse, lieu, référence cadastrale) |
| string | non | Index : |
| number | non | Nombre de résultats (1–50, défaut : 10) |
| number | non | Point de proximité pour favoriser les résultats proches |
|
| non | Active l'autocomplétion (défaut : |
| boolean | non | Retourne la vraie géométrie |
| string | non | Filtre code postal (address, poi) |
| string | non | Filtre code INSEE (address, poi) |
| string | non | Filtre code département (address, poi) |
| string | non | Type d'adresse : |
| string | non | Filtre par commune |
| string | non | Filtre catégorie POI (poi uniquement) |
| string | non | Filtres cadastraux (parcel uniquement) |
Exemples de requêtes :
q=10 rue de la Paix Paris
q=cimetière Vincennes, index=poi
q=75056104AE0003, index=parcel
geocode_reverseGéocodage inverse via GET https://data.geopf.fr/geocodage/reverse.
Paramètres principaux :
Nom | Type | Requis | Description |
| number | oui* | Longitude du point de recherche |
| number | oui* | Latitude du point de recherche |
| string | non | Géométrie JSON (Point, Circle, Polygon, LineString). Si fournie, |
| string | non |
|
| number | non | 1–50, défaut 10 |
| string | non | Filtre type d'adresse (address) |
| string | non | Filtres address/poi |
| string | non | Filtre catégorie POI |
* Requis si searchgeom absent.
Exemple Circle :
{ "type": "Circle", "coordinates": [2.294469, 48.858244], "radius": 100 }geocode_capabilitiesRetourne les capacités de l'API via GET https://data.geopf.fr/geocodage/getCapabilities :
opérations disponibles, index, champs interrogeables, valeurs de catégories POI, etc.
Aucun paramètre requis.
geocodage-mcp/
├── index.js # Entrée MCP : déclaration des outils + connexion stdio
├── package.json
└── src/
├── client.js # Client HTTP fetch vers l'API Géoplateforme
└── tools/
├── search.js # Schéma Zod + handler geocode
├── reverse.js # Schéma Zod + handler geocode_reverse
└── capabilities.js # Handler geocode_capabilities{
"servers": {
"geocodage": {
"type": "stdio",
"command": "node",
"args": ["/chemin/vers/geocodage-mcp/index.js"]
}
}
}claude_desktop_config.json){
"mcpServers": {
"geocodage": {
"command": "node",
"args": ["/chemin/vers/geocodage-mcp/index.js"]
}
}
}Configuration :
Requête initiale :
10 rue du chateau avec @mcp:geocodage: ?Used MCP tool: geocodage/geocode
En cherchant "10 rue du chateau" sans préciser de ville avec l'outil MCP geocodage, l'API retourne plusieurs correspondances possibles, car c'est une adresse très courante en France.
Voici les 5 correspondances les plus pertinentes :
10 Rue du Château, 92600 Asnières-sur-Seine
Longitude : 2.28736
Latitude : 48.906493
10 rue du Château, 29200 Brest
Longitude : -4.490812
Latitude : 48.383654
10 Rue du Château, 44000 Nantes
Longitude : -1.552009
Latitude : 47.216291
10 Rue du Chateau, 21000 Dijon
Longitude : 5.037218
Latitude : 47.323033
10 Rue du Château, 92500 Rueil-Malmaison
Longitude : 2.180793
Latitude : 48.875649
Souhaitez-vous préciser une ville ou un code postal pour affiner ce résultat, ou cherchez-vous les coordonnées d'une de ces villes en particulier ?
et à Seurre ?Pour le 10 Rue du Château à Seurre (21250), l'outil MCP geocodage trouve bien cette adresse unique. Voici les coordonnées précises :
Longitude : 5.145836
Latitude : 46.997484
Si vous souhaitez visualiser cette position exacte sur une carte (avec un fort niveau de zoom), voici les liens d'accès direct correspondants :
Géocode une chaîne de caractères (adresse, lieu ou parcelle cadastrale) via l'API Géoplateforme de l'IGN. Retourne une FeatureCollection GeoJSON.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Chaîne décrivant la localisation à rechercher (adresse, lieu, parcelle). Exemple : '10 rue de la Paix Paris', 'cimetière Vincennes', '75056104AE0003'. | |
| lat | No | Latitude d'un point pour favoriser les candidats les plus proches. | |
| lon | No | Longitude d'un point pour favoriser les candidats les plus proches. | |
| city | No | Filtre par nom de commune (address, poi). Ex : 'Dijon'. | |
| type | No | Filtre par type d'adresse (address uniquement) : 'housenumber', 'street', 'locality', 'municipality'. | |
| index | No | Index de recherche : 'address' (défaut), 'poi' (lieux/POI), 'parcel' (parcelles cadastrales). | |
| limit | No | Nombre maximum de résultats (1–50, défaut : 10). | |
| sheet | No | Filtre par feuille cadastrale (parcel). | |
| number | No | Filtre par numéro de parcelle (parcel). Ex : '0133'. | |
| depcode | No | Filtre par code département (address, poi). Ex : '75'. | |
| section | No | Filtre par section cadastrale (parcel). Ex : 'AV'. | |
| category | No | Filtre par catégorie de POI (poi uniquement, valeurs listées dans getCapabilities). Plusieurs valeurs séparées par des virgules. | |
| citycode | No | Filtre par code INSEE de commune (address, poi). Ex : '75113'. | |
| postcode | No | Filtre par code postal (address, poi). Ex : '75013'. | |
| autocomplete | No | Active (1) ou désactive (0) l'autocomplétion (défaut : 1). | 1 |
| departmentcode | No | Filtre par code département (parcel). Ex : '21'. | |
| municipalitycode | No | Filtre par code commune (parcel). Ex : '231'. | |
| returntruegeometry | No | Retourne la vraie géométrie de l'objet (limite le résultat à 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output format (FeatureCollection GeoJSON) and the data source (IGN Géoplateforme API), but it does not explicitly state that the tool is read-only, nor does it mention any rate limits, geographic scope (likely limited to France), or other behavioral traits beyond the return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for the main action and one for the output. It front-loads the core purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 18 parameters, no output schema, and no annotations, the description is too sparse. It does not explain typical usage, parameter interactions, or the structure of the returned FeatureCollection. It lacks completeness for a complex geocoding tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 18 parameters well. The description adds no additional meaning beyond the schema, only stating it geocodes a string. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool geocodes a string (address, place, or cadastral parcel) via the IGN Géoplateforme API and returns a FeatureCollection GeoJSON. However, it does not explicitly differentiate from sibling tools like geocode_reverse or geocode_capabilities, though the forward geocoding purpose is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool or when not to use it. It does not mention alternative tools for reverse geocoding or capabilities retrieval, which would be helpful given the sibling tools exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retourne les capacités de l'API Géoplateforme : opérations disponibles, index et champs interrogeables, catégories de POI, etc.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description indicates it returns data but does not explicitly state it is read-only or non-destructive. For a simple read operation, the transparency is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. It could be slightly more structured, but it efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is mostly complete. It covers the main aspects of what is returned, though the trailing 'etc.' leaves some vagueness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 params), so the baseline is 4. The description adds meaning by explaining what the output contains (operations, indexes, categories), which adds value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns capabilities of the Géoplateforme API, listing specific elements like operations, indexes, and POI categories. This distinguishes it from sibling tools 'geocode' and 'geocode_reverse', which perform actual geocoding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for obtaining API capabilities, likely before using geocode or geocode_reverse. However, it does not explicitly state when to use it versus alternatives or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Géocodage inverse via l'API Géoplateforme de l'IGN : retourne les adresses/lieux/parcelles les plus proches d'un point géographique (lon/lat) ou d'une géométrie (cercle, polygone…).
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude du point de recherche (ou d'ordonnancement si searchgeom est fourni). Ex : 47.330361. | |
| lon | Yes | Longitude du point de recherche (ou d'ordonnancement si searchgeom est fourni). Ex : 5.022839. | |
| city | No | Filtre par nom de commune. | |
| type | No | Filtre par type d'adresse (address uniquement). | |
| index | No | Index de recherche : 'address' (défaut), 'poi', 'parcel'. Plusieurs valeurs possibles séparées par une virgule. | |
| limit | No | Nombre maximum de résultats (1–50, défaut : 10). | |
| number | No | Filtre par numéro de parcelle (parcel). | |
| section | No | Filtre par section cadastrale (parcel). | |
| category | No | Filtre par catégorie de POI (poi uniquement). | |
| citycode | No | Filtre par code INSEE (address, poi). | |
| postcode | No | Filtre par code postal (address, poi). | |
| searchgeom | No | Géométrie de recherche au format JSON (Point, LineString, Polygon, Circle). Si absent, lon/lat définissent le point de recherche. Exemple Circle : '{"type":"Circle","coordinates":[2.294469,48.858244],"radius":100}'. | |
| departmentcode | No | Filtre par code département (parcel). | |
| municipalitycode | No | Filtre par code commune (parcel). | |
| returntruegeometry | No | Retourne la vraie géométrie de l'objet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It states the tool returns the closest addresses/places/parcels and accepts point or geometry input, but does not disclose rate limits, authentication requirements, default behavior (e.g., index default), or error handling. It is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise with no redundant information. It front-loads the purpose and API source. However, for a tool with 15 parameters, a bulleted list of return types or key options could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (15 params, no output schema, no annotations), the description lacks explanation of default index (address), the difference between point and geometry search, or what the results contain. It is moderately complete but leaves gaps that the rich parameter schema partially fills.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds overall context (e.g., searchgeom can be Circle) but does not provide new meaning beyond the detailed parameter descriptions in the schema. It rephrases but does not deepen understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as reverse geocoding via the IGN API, specifying it returns addresses, places, and parcels closest to a geographic point or geometry. It distinguishes itself from sibling tools (e.g., geocode, which likely does forward geocoding) by explicitly stating 'reverse geocoding'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool compared to siblings (geocode, geocode_capabilities) or when not to use it. It does not mention prerequisites, alternatives, or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.0geocodegeocode_capabilitiesgeocode_reverseScored across 3 tools
Each tool has a distinct purpose: forward geocoding, reverse geocoding, and API capabilities. No overlap.
All tool names follow the 'geocode' prefix with a descriptive suffix (geocode, geocode_reverse, geocode_capabilities), creating a predictable pattern.
Three tools is minimal but sufficient for a geocoding server, covering forward, reverse, and capabilities. Slightly on the low end but appropriate for the domain.
Essential geocoding operations (forward and reverse) are present, along with capabilities. Missing batch or autocomplete, but core workflow is covered.
Base Adresse Nationale (BAN) MCP — France's official keyless geocoding API
Nominatim MCP — wraps OpenStreetMap Nominatim geocoding API (free, no auth)
MCP server for Japan geodata: cadastral lot numbers (chiban) and reverse geocoding, for AI agents.
Geospatial MCP server for earthquake, tsunami, volcano, disaster, and FX data queries.