The geocontext server provides spatial context and geographic data to LLMs, leveraging France's Géoplateforme (IGN) APIs.
Core geographic tools:
Geocoding (geocode): Convert a place name or address into coordinates (longitude, latitude)
Altitude (altitude): Get elevation for a given position
Administrative info (adminexpress): Retrieve commune, canton, EPCI, département, région, and arrondissement for a position
Cadastral data (cadastre): Access parcel, sheet, and fiscal subdivision data for a position
Urban planning (urbanisme): Get applicable PLU, PLUi, POS, CC, or PSMV documents for a position
Public utility easements (assiette_sup): Retrieve Servitudes d'Utilité Publique (SUP) for a position
WFS data exploration (700+ feature types):
List types (gpf_wfs_list_types): List all known WFS feature types from the embedded schema catalog
Search types (gpf_wfs_search_types): Find relevant WFS types by keyword
Describe type (gpf_wfs_describe_type): Get the detailed schema (fields, description) of a specific WFS type
Fetch features (gpf_wfs_get_features): Query live Géoplateforme WFS data with support for CQL filters, property selection, sorting, and result count control
Provides spatial context for LLMs by integrating with French geographic data services, including geocoding, altitude calculation, administrative boundaries (AdminExpress), cadastral information, urban planning documents, and WFS data exploration from the Géoplateforme.
Supports deployment via Docker Compose for running the geocontext MCP server.
Click on "Install 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., "@geocontext what's the altitude at the Eiffel Tower in 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.
Geocontext est un serveur MCP qui permet aux assistants IA d’interroger les données géographiques françaises de référence publiées sur la Géoplateforme de l'IGN.
Pas de téléchargement — Geocontext interroge directement les services de la Géoplateforme IGN, sans copie locale ni synchronisation à maintenir.
Données de référence à jour — les réponses s’appuient sur les référentiels géographiques publiés en continu par l’IGN et ses partenaires.
Réponses optimisées pour les LLM — les traitements et filtrages sont faits côté serveur pour limiter les tokens transmis au modèle.
Moins d’hallucinations — les descriptions et schémas enrichis aident l’assistant à identifier les bonnes données et les bons champs (implémentation anticipée de OGC API Feature - schema dans ignfab/gpf-schema-store).
Compatible MCP — utilisable avec des clients compatibles MCP comme Claude Desktop ou Cursor, mais aussi directement dans certaines interfaces de chat en ligne compatibles, comme Claude, Mistral Vibe ou ChatGPT, via leurs connecteurs MCP.
Related MCP server: French Open Data & IGN
Question
Combien y a-t-il de bâtiments de plus de 20 mètres à Vincennes ?
Réponse
À Vincennes (94300, Val-de-Marne), il y a 509 bâtiments de plus de 20 mètres de hauteur, selon les données de la BD TOPO® de l'IGN.
La hauteur prise en compte est celle mesurée entre le sol et le point haut de la gouttière du bâtiment.
Trace complète
💬 Je vais d'abord rechercher les informations nécessaires :
les coordonnées de Vincennes et le type GPF pour les bâtiments.
🔧 Appel outil: geocode({'text': 'Vincennes'})
🔧 Appel outil: gpf_search_types({'query': 'bâtiment hauteur'})
💬 Parfait ! J'ai trouvé le type GPF BDTOPO_V3:batiment.
Je vais maintenant récupérer le schéma de ce type pour connaître
les propriétés exactes, notamment la hauteur et le code INSEE de Vincennes.
🔧 Appel outil: gpf_describe_type({'typename': 'BDTOPO_V3:batiment'})
🔧 Appel outil: adminexpress({'lon': 2.437785,'lat': 48.847279})
💬 J'ai toutes les informations nécessaires.
La commune de Vincennes a le feature_id commune.33667.
Je vais maintenant compter les bâtiments de plus de 20 mètres
de hauteur sur cette commune.
🔧 Appel outil: gpf_count_features({
'typename': 'BDTOPO_V3:batiment',
'where': [
{
'property': 'hauteur',
'operator': 'gt',
'value': '20'
}
],
'intersects_feature_filter': {
'typename': 'ADMINEXPRESS-COG.LATEST:commune',
'feature_id': 'commune.33667'
}
})
💬 À Vincennes (`94300`, Val-de-Marne), il y a **509 bâtiments**
de plus de **20 mètres de hauteur**, selon les données
de la **BD TOPO®** de l'IGN.
La hauteur prise en compte est celle mesurée entre le sol
et le point haut de la gouttière du bâtiment.Geocontext est disponible comme serveur MCP distant en HTTP : https://geollm.beta.ign.fr/geocontext/mcp
Exemple de configuration pour un client compatible MCP acceptant les serveurs HTTP distants :
{
"mcpServers": {
"geocontext": {
"type": "http",
"url": "https://geollm.beta.ign.fr/geocontext/mcp"
}
}
}Selon le client utilisé, la syntaxe exacte peut varier. Certaines interfaces de chat compatibles MCP demandent simplement l’URL du serveur distant dans leurs paramètres de connecteurs.
Prérequis : Node.js (
>=22.21.0 <23,>=24.5.0recommandé, à contrôler avecnode --version) avecnpx.
Vous pouvez lancer Geocontext vous-même en local avec la commande npx -y @ignfab/geocontext qui démarrera la dernière version publiée de @ignfab/geocontext ou laisser un client MCP comme Cursor le démarrer pour vous via sa configuration.
Par exemple, dans Cursor ("Settings" > "MCP" > "Add server"):
{
"mcpServers": {
"geocontext": {
"command": "npx",
"args": ["-y", "@ignfab/geocontext"]
}
}
}Les fonctionnalités correspondent aux outils MCP documentés dans docs/mcp-tools.md.
Usage | Outil MCP | Source utilisée | Exemple |
Géocoder un lieu |
| Localiser une mairie | |
Obtenir une altitude |
| Altitude d'un point | |
Récupérer le contexte administratif |
| Commune, département, région | |
Récupérer le cadastre |
| Parcelle cadastrale | |
Récupérer les documents d'urbanisme |
| PLU, POS, CC | |
Récupérer les servitudes |
| SUP autour d'un lieu | |
Trouver une couche GPF |
| Trouver la table des bâtiments | |
Décrire une couche GPF |
| Lister les champs disponibles | |
Interroger une couche GPF |
| Extraire des objets | |
Compter les objets résultats d'une interrogation de couche GPF |
| Compter les bâtiments d'une zone | |
Récupérer un objet par identifiant |
| Charger une commune précise | |
Télécharger le résultat d'une interrogation de couche GPF |
| Cartographier un résultat | |
Télécharger un objet par identifiant |
| Cartographier un objet |
Geocontext agit comme un intermédiaire entre un assistant compatible MCP et les services de la Géoplateforme IGN.
Il n’héberge pas les données : il expose des outils MCP, interroge les services IGN à la demande, puis retourne au LLM des réponses structurées, filtrées et adaptées à son contexte.
flowchart TB
assistant["Assistant IA / client MCP"]
geocontext["Geocontext<br/>serveur MCP"]
geopf["Géoplateforme IGN<br/>géocodage · altimétrie · WFS · urbanisme · cadastre"]
assistant -->|"appels d'outils MCP"| geocontext
geocontext -->|"requêtes aux services IGN"| geopf
geopf -->|"données de référence"| geocontext
geocontext -->|"réponses structurées"| assistantEn pratique, Geocontext permet à l’assistant de passer d’une question en langage naturel à des appels aux données géographiques de référence, sans téléchargement préalable ni copie locale des référentiels.
🧪 Ce projet est un prototype en incubation au sein d'IGNfab, basé sur un prototype antérieur désormais archivé. S'il s'avère pertinent de l'industrialiser, il sera migré vers l'organisation IGN principale (ex. : IGNF/mcp-gpf-server).
🪄 Cet outil n'est pas magique : ses capacités sont strictement définies et documentées dans la section Fonctionnalités.
La documentation détaillée est répartie par usage :
Installer Geocontext dans un client MCP
Configurer le serveur MCP
Configuration avancée : proxy d’entreprise, modes de transport stdio / http, paramètres d’exécution.
Comprendre les outils disponibles
Outils MCP : description technique des outils exposés par Geocontext, paramètres attendus et exemples d’appels.
Développer ou contribuer au code
Guide développeur : installation des dépendances, construction de l’application, exécution des tests et organisation du projet.
N'hésitez pas à créer une issue si vous rencontrez un problème !
Merci de fournir :
Le client MCP (ex. : GitHub Copilot, Cursor, Claude Desktop) et le mode de transport (stdio ou http) utilisé.
Le modèle utilisé (ex. : Claude Sonnet 4.5)
La version de Geocontext (visible sur npmjs.com/@ignfab/geocontext)
La demande faite à l'assistant (ex. : "Combien y a-t-il de ponts franchissant la Seine ?")
Si possible, un export de la discussion au format Markdown.
N'hésitez pas non plus à créer une issue pour demander une évolution.
Merci de fournir la question type pour laquelle vous souhaiteriez que le MCP aide à apporter une réponse. Par exemple :
"Quels sont les fonds de carte disponibles ?" -> nous verrons comment exploiter le service WMTS de la Géoplateforme.
mcp-framework : cadre de développement du MCP
@ignfab/gpf-schema-store : couche sémantique / catalogue de schémas embarqué (en attendant OGC API - Features - schema)
@camptocamp/ogc-client : exploration WFS (ex. : parsing GetCapabilities)
MiniSearch : recherche par mot-clé (gpf_search_types)
jsts : traitements géométriques (ex. : tri des réponses par distance au point recherché).
turfjs/distance : calculs de distance avec la formule de Haversine.
https://github.com/datagouv/datagouv-mcp : MCP data.gouv.fr
Exemple : Qui est le maire de la commune de Vincennes ?
https://git.tricoteuses.fr/logiciels/tricoteuses-api-parlement : MCP parlement français non officiel
https://github.com/datagouv/datagouv-skill : Skills data.gouv.fr
Renvoie, pour un point donné par sa longitude et sa latitude, la liste des unités administratives (arrondissement, arrondissement_municipal, canton, collectivite_territoriale, commune, commune_associee_ou_deleguee, departement, epci, region) qui le couvrent, sous forme d'objets typés contenant leurs propriétés administratives.
Les résultats incluent un feature_ref WFS réutilisable. Les propriétés incluent notamment le code INSEE.
Le feature_ref de chaque unité administrative est directement réutilisable dans gpf_wfs_get_features avec spatial_operator="intersects_feature" pour interroger d'autres données sur cette emprise.
Pour récupérer exactement l'objet correspondant au feature_ref, utiliser gpf_wfs_get_feature_by_id.
(source : Géoplateforme (WFS, ADMINEXPRESS-COG.LATEST)).
| Name | Required | Description | Default |
|---|---|---|---|
| lon | Yes | La longitude du point. | |
| lat | Yes | La latitude du point. |
| Name | Required | Description |
|---|---|---|
| results | Yes | La liste des unités administratives couvrant le point demandé. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Les annotations indiquent déjà que l'outil est en lecture seule et idempotent. La description ajoute des informations comportementales utiles : les résultats sont des objets typés avec propriétés administratives et un feature_ref réutilisable. Il n'y a pas de contradiction avec les annotations.
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?
La description est concise et place l'objectif principal en début de phrase. Elle est légèrement longue mais sans information redondante. Les phrases sont bien structurées.
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?
Avec un schéma de sortie existant (non affiché mais indiqué comme présent), la description explique la structure du retour (liste d'objets typés avec propriétés et feature_ref) et la source. Pour un outil simple à 2 paramètres, c'est complet.
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?
Le schéma couvre à 100 % les paramètres (lon, lat) avec descriptions. La description ne fait que répéter qu'il s'agit de longitude et latitude, sans ajouter de détails sémantiques supplémentaires. Score de base 3.
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?
Le titre et la description indiquent clairement que l'outil renvoie la liste des unités administratives pour un point donné par longitude/latitude, avec une distinction claire par rapport aux outils frères comme gpf_wfs_get_features.
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?
La description explique quand utiliser l'outil (obtenir les unités administratives pour un point) et mentionne que le feature_ref peut être réutilisé dans d'autres outils. Elle ne mentionne pas explicitement quand ne pas l'utiliser, mais le contexte est suffisant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Renvoie l'altitude (en mètres) et la précision de la mesure (accuracy) d'un point géographique à partir de sa longitude et de sa latitude. (source : Géoplateforme (altimétrie)).
| Name | Required | Description | Default |
|---|---|---|---|
| lon | Yes | La longitude du point. | |
| lat | Yes | La latitude du point. |
| Name | Required | Description |
|---|---|---|
| lon | Yes | La longitude du point. |
| lat | Yes | La latitude du point. |
| altitude | Yes | L'altitude du point. |
| accuracy | Yes | L'information de précision associée à l'altitude. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly (true), destructiveHint (false), idempotentHint (true). The description adds the data source (Géoplateforme) and output fields (altitude, accuracy), providing value beyond the structured information.
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?
Two sentences, no wasted words, includes source citation. Efficient and front-loaded with key information.
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 that an output schema exists (context signal), the description need not detail return format. It mentions altitude and accuracy, and annotations cover safety. Complete for a simple lookup 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 lon/lat fully. The description adds minimal extra meaning ('longitude' and 'latitude' are implicit). 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 it returns altitude and accuracy for a geographic point given longitude and latitude, distinguishing it from sibling tools like geocode (address to coordinates) and cadastre (parcel data).
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?
No explicit guidance on when to use this tool vs alternatives. The context signals (readOnly, idempotent) imply it's safe but don't specify scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Renvoie, pour un point donné par sa longitude et sa latitude, la liste des assiettes de servitudes d'utilité publique (SUP) pertinentes à proximité, avec leurs propriétés associées.
Une SUP est une contrainte légale sur l'usage du sol liée à un équipement ou une infrastructure publique (ex : AC pour patrimoine, EL pour voirie, PT pour télécoms, I pour installations classées...).
Les résultats peuvent inclure des assiettes ponctuelles, linéaires ou surfaciques et exposent un feature_ref WFS réutilisable quand il est disponible.
Pour récupérer exactement l'objet correspondant au feature_ref, utiliser gpf_wfs_get_feature_by_id.
(source : Géoplateforme - (WFS Géoportail de l'Urbanisme)).
| Name | Required | Description | Default |
|---|---|---|---|
| lon | Yes | La longitude du point. | |
| lat | Yes | La latitude du point. |
| Name | Required | Description |
|---|---|---|
| results | Yes | La liste des assiettes de servitudes d'utilité publique pertinentes pour le point demandé. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint, destructiveHint false, idempotentHint true, openWorldHint true. The description adds behavioral details beyond annotations: mentions return types (ponctuelles, linéaires, surfaciques), exposure of feature_ref, and the source. It does not cover performance or rate limits, but the annotations already handle safety. The description adds moderate context.
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 concise with three sentences including a parenthetical source. It efficiently conveys purpose, examples, and usage of feature_ref. Well-structured and front-loaded, though could be slightly more compact.
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 of SUP concepts and the existence of an output schema, the description is complete. It explains what a SUP is, gives examples, mentions return types, and references a sibling tool. It could include an example response but output schema likely covers that.
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% with 'lon' and 'lat' clearly described. The description confirms the parameters are for specifying a point but does not add new semantics beyond what the schema provides. 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 it returns the list of servitudes d'utilité publique (SUP) for a given point. It explains the concept of SUP, lists examples, and distinguishes from sibling tools like geocode and gpf_wfs_get_feature_by_id. The verb 'Renvoie' and the resource 'assiettes de servitudes d'utilité publique' are specific.
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 explicitly provides an alternative tool for retrieving the exact object via feature_ref: 'Pour récupérer exactement l'objet correspondant au feature_ref, utiliser gpf_wfs_get_feature_by_id.' This gives clear when-not-to-use and directs to a sibling tool. The context of being a point-of-interest query for SUP is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Renvoie, pour un point donné par sa longitude et sa latitude, la liste des objets cadastraux (arrondissement, commune, feuille, parcelle, subdivision_fiscale, localisant) les plus proches, avec leurs informations associées.
Les résultats sont retournés au plus une fois par type lorsqu'ils sont disponibles et incluent un feature_ref WFS réutilisable.
Le feature_ref est directement réutilisable dans gpf_wfs_get_features avec spatial_operator="intersects_feature".
La distance de recherche est fixée à 10 mètres. Si aucun objet n'est trouvé dans les 10 mètres, le résultat est vide.
Pour récupérer exactement l'objet correspondant au feature_ref, utiliser gpf_wfs_get_feature_by_id.
(source : Géoplateforme (WFS, CADASTRALPARCELS.PARCELLAIRE_EXPRESS)).
| Name | Required | Description | Default |
|---|---|---|---|
| lon | Yes | La longitude du point. | |
| lat | Yes | La latitude du point. |
| Name | Required | Description |
|---|---|---|
| results | Yes | La liste des objets cadastraux les plus proches du point demandé. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and read-only behavior, but the description adds critical context: search distance fixed at 10 meters, empty result if no object found, and deduplication by type. The source is also noted.
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 concise and front-loaded with the primary action, but the structure is a single dense paragraph. Minor improvement could be achieved with bullet points or shorter sentences.
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's simplicity (2 read-only parameters), the description fully covers purpose, behavior, edge cases, and integration with sibling tools. Output schema exists, so return values need not be detailed.
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% with clear descriptions for lon and lat. The description reiterates them in context but adds no new semantics beyond the schema. 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 returns cadastral objects near a given longitude/latitude, with details and a reusable feature_ref. It distinguishes from siblings by mentioning alternative tools for specific use cases.
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 explicit guidance on when to use this tool (for cadastral data near a point) and how to reuse the feature_ref in other tools like gpf_wfs_get_features and gpf_wfs_get_feature_by_id. However, it lacks explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Renvoie des résultats d'autocomplétion géocodés à partir d'un texte libre (lieu, adresse, POI), avec coordonnées, libellé complet et informations de localisation (kind, city, zipcode).
Les coordonnées lon/lat retournées sont directement réutilisables dans tous les autres tools. Le champ kind indique le type de résultat (ex : monument, street, city, locality).
(source : Géoplateforme (service d'autocomplétion)).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Le texte devant être completé et géocodé | |
| maximumResponses | No | Le nombre maximum de résultats à retourner (entre 1 et 10). Défaut : 3. |
| Name | Required | Description |
|---|---|---|
| results | Yes | La liste ordonnée des résultats géocodés. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Les annotations couvrent déjà la sécurité (readOnlyHint, idempotentHint, etc.). La description ajoute des détails comportementaux comme les champs retournés (kind, city, zipcode) et la source, ce qui est utile au-delà des annotations.
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?
La description est concise, en deux paragraphes bien structurés, sans information superflue. Le verbe d'action et le résultat sont placés en premier.
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?
Avec un schéma de sortie présent et des annotations riches, la description est suffisamment complète. Elle couvre l'essentiel des informations nécessaires à l'utilisation (résultats, coordonnées, source). Pourrait mentionner les limites de la source, mais reste adéquate.
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?
Le schéma couvre 100% des paramètres, donc la baseline est de 3. La description ajoute des exemples de texte libre ('lieu, adresse, POI'), ce qui enrichit la sémantique du paramètre 'text'.
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?
La description indique clairement que l'outil renvoie des résultats d'autocomplétion géocodés avec coordonnées, libellé et informations de localisation. Elle mentionne aussi que les coordonnées sont réutilisables dans d'autres outils, ce qui précise l'usage.
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?
La description ne donne pas de directives explicites sur quand utiliser cet outil par rapport à ses alternatives, mais elle précise que les coordonnées retournées sont réutilisables dans tous les autres outils, ce qui indique un cas d'usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Renvoie le schéma détaillé d'un type WFS à partir de son identifiant (typename) : identifiants, description et liste des propriétés.
Utiliser ce tool après gpf_wfs_search_types pour inspecter les propriétés disponibles avant d'appeler gpf_wfs_get_features.
La sortie inclut notamment le type des propriétés, leur description, leurs valeurs possibles (enum) lorsqu'elles existent
IMPORTANT: Appel fortement recommandé si les noms exacts des propriétés ne sont pas connus : un nom de propriété incorrect provoque une erreur.
| Name | Required | Description | Default |
|---|---|---|---|
| typename | Yes | Le nom du type (ex : BDTOPO_V3:batiment) |
| Name | Required | Description |
|---|---|---|
| id | Yes | L'identifiant complet du type WFS. |
| namespace | Yes | L'espace de nommage du type WFS. |
| name | Yes | Le nom court du type WFS. |
| title | Yes | Le titre lisible du type WFS. |
| description | Yes | La description du type WFS. |
| properties | Yes | La liste des propriétés du type WFS. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds that output includes property types, descriptions, and enums, plus a strong warning about errors on incorrect names.
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?
Concise, front-loaded with purpose, then usage, then output details, then important note. Every sentence adds value with no redundancy.
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 simple single-parameter tool with output schema present, the description provides sufficient context: purpose, workflow position, output highlights, and critical error warning.
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% with a description for the only parameter. The description adds context by giving an example value (BDTOPO_V3:batiment) and reinforcing the requirement for exact names.
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 the detailed schema of a WFS type (identifiers, description, list of properties) from a typename. It distinguishes itself from siblings by positioning itself between gpf_wfs_search_types and gpf_wfs_get_features.
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?
Explicitly states to use after gpf_wfs_search_types and before gpf_wfs_get_features. Also warns that an incorrect property name causes an error, implying when-to-use and caution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Récupère exactement un objet WFS à partir de typename et feature_id, sans filtre attributaire ni spatial.
Ce tool est le chemin robuste quand vous disposez déjà d'une feature_ref { typename, feature_id } issue d'un autre tool (adminexpress, cadastre, urbanisme, assiette_sup, gpf_wfs_get_features).
Le contrat garantit une cardinalité stricte : 0 résultat ou plusieurs résultats provoquent une erreur explicite.
Utiliser result_type="request" pour récupérer la requête WFS compilée (avec get_url) et l'utiliser ou la visualiser ailleurs.
| Name | Required | Description | Default |
|---|---|---|---|
| typename | Yes | Nom exact du type WFS à interroger, par exemple `ADMINEXPRESS-COG.LATEST:commune`. | |
| feature_id | Yes | Identifiant WFS exact de l'objet à récupérer, par exemple `commune.8952`. | |
| result_type | No | `results` renvoie une FeatureCollection normalisée avec exactement un objet. `request` renvoie la requête WFS compilée (`get_url`) à destination de `create_map` via `geojson_url`, ou pour déboguer. | results |
| select | No | Liste des propriétés non géométriques à renvoyer. Quand `result_type="request"`, la géométrie est automatiquement ajoutée. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds unique behavioral details: strict cardinality guarantee (error on zero or multiple results) and the effect of result_type on output. No contradictions.
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?
Three sentences, each providing essential info: core action, usage context with sibling references, cardinality guarantee, and additional result_type guidance. No redundancy.
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?
Covers main aspects: purpose, usage context, cardinality, result_type usage. Lacks explicit mention of output format for 'results' (FeatureCollection) but it is implied and described. Enough for a focused retrieval tool without output schema.
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 context: clarifies 'sans filtre attributaire ni spatial' (no filters) and explains the result_type enum and select behavior (geometry auto-added for request).
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 states 'Récupère exactement un objet WFS' and specifies the parameters (typename, feature_id) and the absence of filters, clearly distinguishing it from sibling tools like gpf_wfs_get_features that retrieve multiple objects.
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?
Explicitly says when to use: when you already have a feature_ref from another tool, and warns about strict cardinality (error on zero or multiple results). It also explains when to use result_type='request' for debugging or visualization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Interroge un type WFS et renvoie des résultats structurés sans demander au modèle d'écrire du CQL ou du WFS.
Utiliser select pour choisir les propriétés, where pour filtrer, order_by pour trier et spatial_operator avec ses paramètres dédiés pour le spatial. Avec result_type="request", la géométrie est automatiquement ajoutée aux propriétés sélectionnées pour garantir une requête cartographiable.
Exemple attributaire : where=[{ property: "code_insee", operator: "eq", value: "75056" }].
Exemple bbox : spatial_operator="bbox" avec bbox_west, bbox_south, bbox_east, bbox_north en lon/lat.
Exemple point dans géométrie : spatial_operator="intersects_point" avec intersects_lon et intersects_lat.
Exemple distance : spatial_operator="dwithin_point" avec dwithin_lon, dwithin_lat, dwithin_distance_m.
Exemple réutilisation : spatial_operator="intersects_feature" avec intersects_feature_typename et intersects_feature_id issus d'une feature_ref.
⚠️ Quand typename et intersects_feature_typename sont identiques, utiliser gpf_wfs_get_feature_by_id pour récupérer exactement l'objet ciblé.
OBLIGATOIRE : toujours appeler gpf_wfs_describe_type avant ce tool, sauf si gpf_wfs_describe_type a déjà été appelé pour ce même typename dans la conversation en cours.
Les noms de propriétés ne peuvent pas être devinés : ils sont spécifiques à chaque typename et diffèrent systématiquement des conventions habituelles (ex : pas de nom_officiel, navigabilite sans accent, etc.). Toute tentative sans appel préalable à gpf_wfs_describe_type provoquera une erreur.
| Name | Required | Description | Default |
|---|---|---|---|
| typename | Yes | Nom exact du type WFS à interroger, par exemple `BDTOPO_V3:batiment`. Utiliser `gpf_wfs_search_types` pour trouver un `typename` valide. | |
| limit | No | Nombre maximum d'objets à renvoyer. Valeur par défaut : 100. Maximum : 5000. | |
| result_type | No | `results` renvoie une FeatureCollection avec les propriétés attributaires uniquement — **les géométries ne sont pas incluses**, ce mode ne peut donc pas être utilisé directement pour cartographier. `hits` renvoie uniquement le nombre total d'objets correspondant à la requête. `request` renvoie l'URL WFS compilée (`get_url`) à destination de `create_map` via `geojson_url`, ou pour déboguer la requête générée. **La géométrie est automatiquement ajoutée aux propriétés du `select`** pour garantir l'affichage cartographique. | results |
| select | No | Liste des propriétés non géométriques à renvoyer pour chaque objet. Utiliser `gpf_wfs_describe_type` pour connaître les noms exacts disponibles. Exemple : `["code_insee", "nom_officiel"]`. | |
| order_by | No | Liste ordonnée des critères de tri. | |
| where | No | Clauses de filtre attributaire, combinées avec `AND`. | |
| spatial_operator | No | Type optionnel de filtre spatial. | |
| bbox_west | No | Longitude ouest en WGS84 `lon/lat`, utilisée avec `spatial_operator = "bbox"`. | |
| bbox_south | No | Latitude sud en WGS84 `lon/lat`, utilisée avec `spatial_operator = "bbox"`. | |
| bbox_east | No | Longitude est en WGS84 `lon/lat`, utilisée avec `spatial_operator = "bbox"`. | |
| bbox_north | No | Latitude nord en WGS84 `lon/lat`, utilisée avec `spatial_operator = "bbox"`. | |
| intersects_lon | No | Longitude du point en WGS84 `lon/lat`, utilisée avec `spatial_operator = "intersects_point"`. | |
| intersects_lat | No | Latitude du point en WGS84 `lon/lat`, utilisée avec `spatial_operator = "intersects_point"`. | |
| dwithin_lon | No | Longitude du point en WGS84 `lon/lat`, utilisée avec `spatial_operator = "dwithin_point"`. | |
| dwithin_lat | No | Latitude du point en WGS84 `lon/lat`, utilisée avec `spatial_operator = "dwithin_point"`. | |
| dwithin_distance_m | No | Distance en mètres, utilisée avec `spatial_operator = "dwithin_point"`. | |
| intersects_feature_typename | No | Type WFS du feature de référence, utilisé avec `spatial_operator = "intersects_feature"`. | |
| intersects_feature_id | No | Identifiant du feature de référence, utilisé avec `spatial_operator = "intersects_feature"`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent, but the description adds critical behaviors: geometry auto-added for request mode, error on missing describe_type, and result_type differences.
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?
Description is long but well-structured with examples and warnings. Each sentence adds value; however, it could be slightly more concise.
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's complexity (18 parameters, spatial operators), the description is comprehensive: covers mandatory prerequisite, error conditions, result formats, and parameter usage. No output schema, but result_type explanations suffice.
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 has 100% coverage, so baseline is 3. The description adds value by grouping spatial operators with their parameters, providing examples, and explaining the purpose of each parameter beyond the 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 queries a WFS type and returns structured results without requiring the model to write CQL or WFS. It distinguishes from sibling tools like gpf_wfs_get_feature_by_id.
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?
Explicitly states when to use (after calling gpf_wfs_describe_type) and when not to (use get_feature_by_id for the same typename). Provides examples and mandatory prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche des types WFS de la Géoplateforme (GPF) à partir de mots-clés afin de trouver un identifiant de type (typename) valide.
La recherche est textuelle (mini-search) et retourne une liste ordonnée de candidats avec leur identifiant, leur titre, leur description et un score de pertinence éventuel.
Le paramètre max_results permet d'élargir le nombre de candidats retournés (10 par défaut).
Important : Utiliser ce tool avant gpf_wfs_describe_type ou gpf_wfs_get_features lorsque le nom exact du type n'est pas connu.
Important : Privilégier des termes métier en français pour la recherche.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | La requête de recherche | |
| max_results | No | Le nombre maximum de résultats à retourner (entre 1 et 50). Défaut : 10. |
| Name | Required | Description |
|---|---|---|
| results | Yes | La liste ordonnée des types WFS trouvés. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, open world. Description adds that it is text-based mini-search returning ordered candidates with id, title, description, relevance score, and notes default max_results. No contradictions.
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?
Description is concise: purpose stated first, then details, then bolded important usage notes. Every sentence earns its place with zero redundancy.
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?
For a search tool with output schema, the description fully covers what the tool does, return fields, and usage context. No gaps given the available annotations and output schema.
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 covers both parameters with descriptions and constraints. Description adds that query is text search and max_results defaults to 10, but this is minimal beyond schema. With 100% schema coverage, 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 it searches for WFS types using keywords to find valid type identifiers. It distinguishes itself from siblings by explicitly positioning itself as a prerequisite to gpf_wfs_describe_type and gpf_wfs_get_features.
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?
Provides explicit when-to-use guidance: before describe_type or get_features when typename unknown. Suggests using French business terms. Does not explicitly state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Renvoie, pour un point donné par sa longitude et sa latitude, la liste des objets d'urbanisme pertinents du Géoportail de l'Urbanisme (document, zones, prescriptions, informations, etc.), avec leurs propriétés associées. (source : Géoplateforme - (WFS Géoportail de l'Urbanisme)).
Les résultats peuvent notamment inclure le document d'urbanisme applicable ainsi que des éléments réglementaires associés à proximité du point.
Quand un objet correspond à une couche WFS réutilisable, il expose aussi un feature_ref compatible avec gpf_wfs_get_features et spatial_operator="intersects_feature".
Le zonage PLU (zone U, AU, A, N...) est inclus dans les zones retournées et constitue souvent l'information principale recherchée.
Pour récupérer exactement l'objet correspondant au feature_ref, utiliser gpf_wfs_get_feature_by_id.
Modèles d'URL Géoportail de l'Urbanisme :
| Name | Required | Description | Default |
|---|---|---|---|
| lon | Yes | La longitude du point. | |
| lat | Yes | La latitude du point. |
| Name | Required | Description |
|---|---|---|
| results | Yes | La liste des objets d'urbanisme pertinents pour le point demandé. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. Description adds context on the nature of results and the feature_ref reuse, enhancing transparency without contradiction.
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?
Description is informative but slightly lengthy; could be more concise. It is front-loaded with the core action and provides necessary details, though some repetition exists.
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 and presence of an output schema, the description covers all essential aspects: what it does, what it returns, how to link to other tools, and provides URL templates. Sufficient for an agent to invoke correctly.
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?
Input schema has 100% coverage with clear descriptions for lon and lat. Description does not add significant meaning beyond what schema already provides, so baseline of 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 it returns a list of urban planning objects for a given point, specifying source and types (documents, zones, prescriptions). It differentiates itself from siblings by mentioning compatibility with gpf_wfs_get_features and gpf_wfs_get_feature_by_id.
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?
Provides explicit guidance on when to use this tool (for urban planning info at a point) and references sibling tools for further queries, plus URL models for accessing documents on Géoportail.
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. Dates show when Glama detected each change.
v0.9.8altitude6 fields changedOutput schema / properties / accuracyAdded value: +{
+ "description": "L'information de précision associée à l'altitude.",
+ "type": "string"
+}Output schema / properties / altitudeAdded value: +{
+ "description": "L'altitude du point.",
+ "type": "number"
+}Output schema / properties / latAdded value: +{
+ "description": "La latitude du point.",
+ "type": "number"
+}Output schema / properties / lonAdded value: +{
+ "description": "La longitude du point.",
+ "type": "number"
+}Output schema / properties / resultRemoved value: -{
- "description": "Le résultat altimétrique pour la position demandée.",
- "properties": {
- "accuracy": {
- "description": "L'information de précision associée à l'altitude.",
- "type": "string"
- },
- "altitude": {
- "description": "L'altitude du point.",
- "type": "number"
- },
- "lat": {
- "description": "La latitude du point.",
- "type": "number"
- },
- "lon": {
- "description": "La longitude du point.",
- "type": "number"
- }
- },
- "required": [
- "lon",
- "lat",
- "altitude",
- "accuracy"
- ],
- "type": "object"
-}Output schema / requiredPrevious value: -[
- "result"
-]New value: +[
+ "lon",
+ "lat",
+ "altitude",
+ "accuracy"
+]gpf_wfs_describe_type8 fields changedOutput schema / properties / descriptionAdded value: +{
+ "description": "La description du type WFS.",
+ "type": "string"
+}Output schema / properties / idAdded value: +{
+ "description": "L'identifiant complet du type WFS.",
+ "type": "string"
+}Output schema / properties / nameAdded value: +{
+ "description": "Le nom court du type WFS.",
+ "type": "string"
+}Output schema / properties / namespaceAdded value: +{
+ "description": "L'espace de nommage du type WFS.",
+ "type": "string"
+}Output schema / properties / propertiesAdded value: +{
+ "description": "La liste des propriétés du type WFS.",
+ "items": {
+ "properties": {
+ "defaultCrs": {
+ "description": "Le système de coordonnées par défaut si la propriété est géométrique.",
+ "type": "string"
+ },
+ "description": {
+ "description": "La description de la propriété.",
+ "type": "string"
+ },
+ "enum": {
+ "description": "Les valeurs possibles de la propriété.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "name": {
+ "description": "Le nom de la propriété.",
+ "type": "string"
+ },
+ "title": {
+ "description": "Le titre lisible de la propriété.",
+ "type": "string"
+ },
+ "type": {
+ "description": "Le type de la propriété.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / resultRemoved value: -{
- "description": "La description détaillée du type WFS.",
- "properties": {
- "description": {
- "description": "La description du type WFS.",
- "type": "string"
- },
- "id": {
- "description": "L'identifiant complet du type WFS.",
- "type": "string"
- },
- "name": {
- "description": "Le nom court du type WFS.",
- "type": "string"
- },
- "namespace": {
- "description": "L'espace de nommage du type WFS.",
- "type": "string"
- },
- "properties": {
- "description": "La liste des propriétés du type WFS.",
- "items": {
- "properties": {
- "defaultCrs": {
- "description": "Le système de coordonnées par défaut si la propriété est géométrique.",
- "type": "string"
- },
- "description": {
- "description": "La description de la propriété.",
- "type": "string"
- },
- "enum": {
- "description": "Les valeurs possibles de la propriété.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "name": {
- "description": "Le nom de la propriété.",
- "type": "string"
- },
- "title": {
- "description": "Le titre lisible de la propriété.",
- "type": "string"
- },
- "type": {
- "description": "Le type de la propriété.",
- "type": "string"
- }
- },
- "required": [
- "name",
- "type"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "title": {
- "description": "Le titre lisible du type WFS.",
- "type": "string"
- }
- },
- "required": [
- "id",
- "namespace",
- "name",
- "title",
- "description",
- "properties"
- ],
- "type": "object"
-}Output schema / properties / titleAdded value: +{
+ "description": "Le titre lisible du type WFS.",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "result"
-]New value: +[
+ "id",
+ "namespace",
+ "name",
+ "title",
+ "description",
+ "properties"
+]v0.9.1gpf_wfs_get_featuresv0.8.2gpf_wfs_get_featuresv0.9.2gpf_wfs_get_featuresv0.9.5gpf_wfs_get_featuresv0.9.6gpf_wfs_get_featuresv0.9.0gpf_wfs_get_featuresv0.8.1adminexpress7 fields changedInput schema / properties / lat / descriptionPrevious value: -"La latitude du point"New value: +"La latitude du point."Input schema / properties / lat / maximumAdded value: +90Input schema / properties / lat / minimumAdded value: +-90Input schema / properties / lon / descriptionPrevious value: -"La longitude du point"New value: +"La longitude du point."Input schema / properties / lon / maximumAdded value: +180Input schema / properties / lon / minimumAdded value: +-180Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "results": {
+ "description": "La liste des unités administratives couvrant le point demandé.",
+ "items": {
+ "properties": {
+ "bbox": {
+ "description": "La boîte englobante de l'unité administrative.",
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "feature_ref": {
+ "description": "Référence WFS réutilisable, notamment avec `gpf_wfs_get_features` et `spatial_operator = \"intersects_feature\"`.",
+ "properties": {
+ "feature_id": {
+ "description": "L'identifiant WFS réutilisable du feature.",
+ "type": "string"
+ },
+ "typename": {
+ "description": "Le `typename` WFS réutilisable pour une requête ultérieure.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "typename",
+ "feature_id"
+ ],
+ "type": "object"
+ },
+ "id": {
+ "description": "L'identifiant de l'unité administrative.",
+ "type": "string"
+ },
+ "type": {
+ "description": "Le type d'unité administrative (arrondissement, arrondissement_municipal, canton, collectivite_territoriale, commune, commune_associee_ou_deleguee, departement, epci, region).",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "id",
+ "feature_ref"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}altitude7 fields changedInput schema / properties / lat / descriptionPrevious value: -"La latitude du point"New value: +"La latitude du point."Input schema / properties / lat / maximumAdded value: +90Input schema / properties / lat / minimumAdded value: +-90Input schema / properties / lon / descriptionPrevious value: -"La longitude du point"New value: +"La longitude du point."Input schema / properties / lon / maximumAdded value: +180Input schema / properties / lon / minimumAdded value: +-180Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "description": "Le résultat altimétrique pour la position demandée.",
+ "properties": {
+ "accuracy": {
+ "description": "L'information de précision associée à l'altitude.",
+ "type": "string"
+ },
+ "altitude": {
+ "description": "L'altitude du point.",
+ "type": "number"
+ },
+ "lat": {
+ "description": "La latitude du point.",
+ "type": "number"
+ },
+ "lon": {
+ "description": "La longitude du point.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "lon",
+ "lat",
+ "altitude",
+ "accuracy"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "type": "object"
+}assiette_sup7 fields changedInput schema / properties / lat / descriptionPrevious value: -"La latitude du point"New value: +"La latitude du point."Input schema / properties / lat / maximumAdded value: +90Input schema / properties / lat / minimumAdded value: +-90Input schema / properties / lon / descriptionPrevious value: -"La longitude du point"New value: +"La longitude du point."Input schema / properties / lon / maximumAdded value: +180Input schema / properties / lon / minimumAdded value: +-180Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "results": {
+ "description": "La liste des assiettes de servitudes d'utilité publique pertinentes pour le point demandé.",
+ "items": {
+ "properties": {
+ "bbox": {
+ "description": "La boîte englobante de l'assiette.",
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "distance": {
+ "description": "La distance en mètres entre le point demandé et l'assiette retenue.",
+ "type": "number"
+ },
+ "feature_ref": {
+ "description": "Référence WFS réutilisable, notamment avec `gpf_wfs_get_features` et `spatial_operator = \"intersects_feature\"`.",
+ "properties": {
+ "feature_id": {
+ "description": "L'identifiant WFS réutilisable du feature.",
+ "type": "string"
+ },
+ "typename": {
+ "description": "Le `typename` WFS réutilisable pour une requête ultérieure.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "typename",
+ "feature_id"
+ ],
+ "type": "object"
+ },
+ "id": {
+ "description": "L'identifiant de l'assiette.",
+ "type": "string"
+ },
+ "type": {
+ "description": "Le type d'assiette de servitude d'utilité publique renvoyé.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "id",
+ "distance"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}cadastre7 fields changedInput schema / properties / lat / descriptionPrevious value: -"La latitude du point"New value: +"La latitude du point."Input schema / properties / lat / maximumAdded value: +90Input schema / properties / lat / minimumAdded value: +-90Input schema / properties / lon / descriptionPrevious value: -"La longitude du point"New value: +"La longitude du point."Input schema / properties / lon / maximumAdded value: +180Input schema / properties / lon / minimumAdded value: +-180Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "results": {
+ "description": "La liste des objets cadastraux les plus proches du point demandé.",
+ "items": {
+ "properties": {
+ "bbox": {
+ "description": "La boîte englobante de l'objet cadastral.",
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "distance": {
+ "description": "La distance en mètres entre le point demandé et l'objet cadastral retenu.",
+ "type": "number"
+ },
+ "feature_ref": {
+ "description": "Référence WFS réutilisable, notamment avec `gpf_wfs_get_features` et `spatial_operator = \"intersects_feature\"`.",
+ "properties": {
+ "feature_id": {
+ "description": "L'identifiant WFS réutilisable du feature.",
+ "type": "string"
+ },
+ "typename": {
+ "description": "Le `typename` WFS réutilisable pour une requête ultérieure.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "typename",
+ "feature_id"
+ ],
+ "type": "object"
+ },
+ "id": {
+ "description": "L'identifiant de l'objet cadastral.",
+ "type": "string"
+ },
+ "source": {
+ "description": "La source des données cadastrales.",
+ "type": "string"
+ },
+ "type": {
+ "description": "Le type d'objet cadastral (arrondissement, commune, feuille, parcelle, subdivision_fiscale, localisant).",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "id",
+ "feature_ref",
+ "distance",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}geocode3 fields changedInput schema / properties / maximumResponsesAdded value: +{
+ "description": "Le nombre maximum de résultats à retourner (entre 1 et 10). Défaut : 3.",
+ "maximum": 10,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / text / minLengthAdded value: +1Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "results": {
+ "description": "La liste ordonnée des résultats géocodés.",
+ "items": {
+ "properties": {
+ "city": {
+ "description": "La commune du résultat.",
+ "type": "string"
+ },
+ "fulltext": {
+ "description": "Le libellé complet du résultat.",
+ "type": "string"
+ },
+ "kind": {
+ "description": "La nature du résultat géocodé.",
+ "type": "string"
+ },
+ "lat": {
+ "description": "La latitude du résultat.",
+ "type": "number"
+ },
+ "lon": {
+ "description": "La longitude du résultat.",
+ "type": "number"
+ },
+ "zipcode": {
+ "description": "Le code postal du résultat.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "lon",
+ "lat",
+ "fulltext"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}gpf_wfs_describe_type2 fields changedInput schema / properties / typename / minLengthAdded value: +1Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "description": "La description détaillée du type WFS.",
+ "properties": {
+ "description": {
+ "description": "La description du type WFS.",
+ "type": "string"
+ },
+ "id": {
+ "description": "L'identifiant complet du type WFS.",
+ "type": "string"
+ },
+ "name": {
+ "description": "Le nom court du type WFS.",
+ "type": "string"
+ },
+ "namespace": {
+ "description": "L'espace de nommage du type WFS.",
+ "type": "string"
+ },
+ "properties": {
+ "description": "La liste des propriétés du type WFS.",
+ "items": {
+ "properties": {
+ "defaultCrs": {
+ "description": "Le système de coordonnées par défaut si la propriété est géométrique.",
+ "type": "string"
+ },
+ "description": {
+ "description": "La description de la propriété.",
+ "type": "string"
+ },
+ "enum": {
+ "description": "Les valeurs possibles de la propriété.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "name": {
+ "description": "Le nom de la propriété.",
+ "type": "string"
+ },
+ "title": {
+ "description": "Le titre lisible de la propriété.",
+ "type": "string"
+ },
+ "type": {
+ "description": "Le type de la propriété.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "title": {
+ "description": "Le titre lisible du type WFS.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "namespace",
+ "name",
+ "title",
+ "description",
+ "properties"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "type": "object"
+}gpf_wfs_get_feature_by_idgpf_wfs_get_features27 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / bbox_eastAdded value: +{
+ "description": "Longitude est en WGS84 `lon/lat`, utilisée avec `spatial_operator = \"bbox\"`.",
+ "maximum": 180,
+ "minimum": -180,
+ "type": "number"
+}Input schema / properties / bbox_northAdded value: +{
+ "description": "Latitude nord en WGS84 `lon/lat`, utilisée avec `spatial_operator = \"bbox\"`.",
+ "maximum": 90,
+ "minimum": -90,
+ "type": "number"
+}Input schema / properties / bbox_southAdded value: +{
+ "description": "Latitude sud en WGS84 `lon/lat`, utilisée avec `spatial_operator = \"bbox\"`.",
+ "maximum": 90,
+ "minimum": -90,
+ "type": "number"
+}Input schema / properties / bbox_westAdded value: +{
+ "description": "Longitude ouest en WGS84 `lon/lat`, utilisée avec `spatial_operator = \"bbox\"`.",
+ "maximum": 180,
+ "minimum": -180,
+ "type": "number"
+}Input schema / properties / countRemoved value: -{
- "description": "Le nombre d'objets à récupérer (ex : 10)",
- "type": "number"
-}Input schema / properties / cql_filterRemoved value: -{
- "description": "Le filtre au format cql_filter de GeoServer. ATTENTION : il faut permuter les coordonnées pour EPSG:4326 (ex : 'DWITHIN(geom,Point(${lat} ${lon}),10,meters)')",
- "type": "string"
-}Input schema / properties / dwithin_distance_mAdded value: +{
+ "description": "Distance en mètres, utilisée avec `spatial_operator = \"dwithin_point\"`.",
+ "exclusiveMinimum": 0,
+ "type": "number"
+}Input schema / properties / dwithin_latAdded value: +{
+ "description": "Latitude du point en WGS84 `lon/lat`, utilisée avec `spatial_operator = \"dwithin_point\"`.",
+ "maximum": 90,
+ "minimum": -90,
+ "type": "number"
+}Input schema / properties / dwithin_lonAdded value: +{
+ "description": "Longitude du point en WGS84 `lon/lat`, utilisée avec `spatial_operator = \"dwithin_point\"`.",
+ "maximum": 180,
+ "minimum": -180,
+ "type": "number"
+}Input schema / properties / intersects_feature_idAdded value: +{
+ "description": "Identifiant du feature de référence, utilisé avec `spatial_operator = \"intersects_feature\"`.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / intersects_feature_typenameAdded value: +{
+ "description": "Type WFS du feature de référence, utilisé avec `spatial_operator = \"intersects_feature\"`.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / intersects_latAdded value: +{
+ "description": "Latitude du point en WGS84 `lon/lat`, utilisée avec `spatial_operator = \"intersects_point\"`.",
+ "maximum": 90,
+ "minimum": -90,
+ "type": "number"
+}Input schema / properties / intersects_lonAdded value: +{
+ "description": "Longitude du point en WGS84 `lon/lat`, utilisée avec `spatial_operator = \"intersects_point\"`.",
+ "maximum": 180,
+ "minimum": -180,
+ "type": "number"
+}Input schema / properties / limitAdded value: +{
+ "default": 100,
+ "description": "Nombre maximum d'objets à renvoyer. Valeur par défaut : 100. Maximum : 5000.",
+ "maximum": 5000,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / order_byAdded value: +{
+ "description": "Liste ordonnée des critères de tri.",
+ "items": {
+ "additionalProperties": false,
+ "description": "Critère de tri structuré. Exemple : `{ property: \"population\", direction: \"desc\" }`.",
+ "properties": {
+ "direction": {
+ "default": "asc",
+ "description": "Direction de tri : `asc` ou `desc`.",
+ "enum": [
+ "asc",
+ "desc"
+ ],
+ "type": "string"
+ },
+ "property": {
+ "description": "Nom exact d'une propriété non géométrique à utiliser pour le tri. Utiliser `gpf_wfs_describe_type` pour connaître les noms exacts disponibles.",
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "property"
+ ],
+ "type": "object"
+ },
+ "minItems": 1,
+ "type": "array"
+}Input schema / properties / property_namesRemoved value: -{
- "description": "La liste des propriétés séparées par des virgules (ex : \"code_insee,nom_officiel,geometrie\"). NB : adapter geometrie avec geometryName au niveau du type WFS. ",
- "type": "string"
-}Input schema / properties / result_type / defaultAdded value: +"results"Input schema / properties / result_type / descriptionPrevious value: -"Type de résultat : \r\n- 'results' pour les données complètes (défaut)\r\n- 'hits' pour le comptage uniquement\r\n- 'url' pour récupérer l'URL de la requête (ex : affichage des données côté client dans une carte)"New value: +"`results` renvoie une FeatureCollection avec les propriétés attributaires uniquement — **les géométries ne sont pas incluses**, ce mode ne peut donc pas être utilisé directement pour cartographier. `hits` renvoie uniquement le nombre total d'objets correspondant à la requête. `request` renvoie l'URL WFS compilée (`get_url`) à destination de `create_map` via `geojson_url`, ou pour déboguer la requête générée. **La géométrie est automatiquement ajoutée aux propriétés du `select`** pour garantir l'affichage cartographique."Input schema / properties / result_type / enumAdded value: +[
+ "results",
+ "hits",
+ "request"
+]Input schema / properties / selectAdded value: +{
+ "description": "Liste des propriétés non géométriques à renvoyer pour chaque objet. Utiliser `gpf_wfs_describe_type` pour connaître les noms exacts disponibles. Exemple : `[\"code_insee\", \"nom_officiel\"]`.",
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+}Input schema / properties / sort_byRemoved value: -{
- "description": "Trier selon une propriété (syntaxe : field1 [A|D], field2 [A|D], ... , fieldN [A|D])",
- "type": "string"
-}Input schema / properties / spatial_operatorAdded value: +{
+ "description": "Type optionnel de filtre spatial.",
+ "enum": [
+ "bbox",
+ "intersects_point",
+ "dwithin_point",
+ "intersects_feature"
+ ],
+ "type": "string"
+}Input schema / properties / typename / descriptionPrevious value: -"Le nom du type (ex : BDTOPO_V3:batiment). Important : Utiliser gpf_wfs_search_types pour trouver les types disponibles."New value: +"Nom exact du type WFS à interroger, par exemple `BDTOPO_V3:batiment`. Utiliser `gpf_wfs_search_types` pour trouver un `typename` valide."Input schema / properties / typename / minLengthAdded value: +1Input schema / properties / whereAdded value: +{
+ "description": "Clauses de filtre attributaire, combinées avec `AND`.",
+ "items": {
+ "additionalProperties": false,
+ "description": "Clause de filtre structurée. Exemple : `{ property: \"code_insee\", operator: \"eq\", value: \"75056\" }`.",
+ "properties": {
+ "operator": {
+ "description": "Opérateur de filtre : `eq`, `ne`, `lt`, `lte`, `gt`, `gte`, `in`, `is_null`.",
+ "enum": [
+ "eq",
+ "ne",
+ "lt",
+ "lte",
+ "gt",
+ "gte",
+ "in",
+ "is_null"
+ ],
+ "type": "string"
+ },
+ "property": {
+ "description": "Nom exact d'une propriété non géométrique du type WFS. Utiliser `gpf_wfs_describe_type` pour connaître les noms exacts disponibles.",
+ "minLength": 1,
+ "type": "string"
+ },
+ "value": {
+ "description": "Valeur scalaire sérialisée en texte, utilisée avec tous les opérateurs sauf `in` et `is_null`.",
+ "type": "string"
+ },
+ "values": {
+ "description": "Liste de valeurs sérialisées en texte, utilisée uniquement avec `operator = \"in\"`.",
+ "items": {
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+ },
+ "required": [
+ "property",
+ "operator"
+ ],
+ "type": "object"
+ },
+ "minItems": 1,
+ "type": "array"
+}gpf_wfs_list_typesgpf_wfs_search_types6 fields changedInput schema / properties / max_results / descriptionPrevious value: -"Le nombre de résultats (10 par défaut)"New value: +"Le nombre maximum de résultats à retourner (entre 1 et 50). Défaut : 10."Input schema / properties / max_results / maximumAdded value: +50Input schema / properties / max_results / minimumAdded value: +1Input schema / properties / max_results / typePrevious value: -"number"New value: +"integer"Input schema / properties / query / minLengthAdded value: +1Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "results": {
+ "description": "La liste ordonnée des types WFS trouvés.",
+ "items": {
+ "properties": {
+ "description": {
+ "description": "La description du type WFS.",
+ "type": "string"
+ },
+ "id": {
+ "description": "L'identifiant complet du type WFS.",
+ "type": "string"
+ },
+ "score": {
+ "description": "Le score de pertinence de la recherche.",
+ "type": "number"
+ },
+ "title": {
+ "description": "Le titre lisible du type WFS.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "description"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}urbanisme7 fields changedInput schema / properties / lat / descriptionPrevious value: -"La latitude du point"New value: +"La latitude du point."Input schema / properties / lat / maximumAdded value: +90Input schema / properties / lat / minimumAdded value: +-90Input schema / properties / lon / descriptionPrevious value: -"La longitude du point"New value: +"La longitude du point."Input schema / properties / lon / maximumAdded value: +180Input schema / properties / lon / minimumAdded value: +-180Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "results": {
+ "description": "La liste des objets d'urbanisme pertinents pour le point demandé.",
+ "items": {
+ "properties": {
+ "bbox": {
+ "description": "La boîte englobante de l'objet d'urbanisme.",
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "distance": {
+ "description": "La distance en mètres entre le point demandé et l'objet d'urbanisme retenu.",
+ "type": "number"
+ },
+ "feature_ref": {
+ "description": "Référence WFS réutilisable, notamment avec `gpf_wfs_get_features` et `spatial_operator = \"intersects_feature\"`.",
+ "properties": {
+ "feature_id": {
+ "description": "L'identifiant WFS réutilisable du feature.",
+ "type": "string"
+ },
+ "typename": {
+ "description": "Le `typename` WFS réutilisable pour une requête ultérieure.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "typename",
+ "feature_id"
+ ],
+ "type": "object"
+ },
+ "id": {
+ "description": "L'identifiant de l'objet d'urbanisme.",
+ "type": "string"
+ },
+ "type": {
+ "description": "Le type d'objet d'urbanisme renvoyé.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "id",
+ "distance"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}v1.0.0adminexpressaltitudeassiette_supcadastregeocodegpf_wfs_describe_typegpf_wfs_get_featuresgpf_wfs_list_typesgpf_wfs_search_typesurbanismeEach tool targets a distinct geographic domain or WFS operation. There is no ambiguity between tools like adminexpress, cadastre, urbanisme, etc. They all have clearly separated purposes.
Most tools use lowercase with underscores (adminexpress, assiette_sup, gpf_wfs_*), but a few are single words (geocode, altitude, urbanisme). The gpf_wfs_ prefix provides consistency for WFS-related tools. Minor deviations prevent a perfect score.
9 tools is well-scoped for a geographic context server. It covers essential data sources (administrative, elevation, cadastre, urbanism, WFS discovery) without being excessive.
The tool surface covers major geographic queries: administrative units, elevation, servitudes, cadastre, geocoding, urban planning, and WFS metadata. Missing are update/delete capabilities, but that aligns with the read-only nature. Slight gap in batch or spatial queries beyond point-based, but sufficient for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
French address quality, geocoding & routing from official data (BAN, INSEE, OpenStreetMap).
Geocode, reverse geocode, and run Overpass spatial queries on OpenStreetMap data.
Geocode, reverse geocode, and run Overpass spatial queries on OpenStreetMap data.
Address validation & geocoding for AI agents: 240+ countries, UK PAF, free US/CA enrichment
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ignfab/geocontext'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
