Nyambot-MCP is a keyless MCP server wrapping French public APIs (geo.api.gouv.fr, Base Adresse Nationale, Géorisques, ADEME) into 4 decision-ready tools for real estate and location intelligence:
resolve_commune – Converts a commune name into its INSEE code, department, region, GPS coordinates, and population. Acts as the geographic anchor for downstream tools.
geocode_address – Normalizes and geocodes a free-text French address via the Base Adresse Nationale, returning coordinates, postal code, commune, and INSEE code.
risques_immobilier – Returns a full natural and technological risk profile for a commune (flooding, clay shrinkage, earthquakes, radon, landslides, industrial sites/ICPE, nuclear, etc.), accepting either an INSEE code or a free-text address. Essential before any real estate purchase.
dpe_logement – Retrieves Energy Performance Certificates (DPE) from the ADEME database for existing housing by postal code, optionally filtered by address, returning energy label (A–G), GHG label, surface area, consumption, and diagnostic date.
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., "@nyambot-mcp Quels sont les risques immobiliers à Lyon ?"
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.
La couche d'intelligence qui rend la donnée publique française exploitable par votre agent IA.
La donnée publique française est ouverte — mais brute, éparpillée sur des dizaines d'APIs, et illisible en contexte. Le vrai défi n'est pas d'y accéder, c'est de la comprendre : quel jeu de données, quelle colonne, quelle interprétation pour cette situation précise. C'est là que Nyambot intervient : un système d'intelligence qui fait ce travail à la place de votre agent — il interroge, croise, contextualise, et renvoie une réponse sourcée et directement exploitable, pas des lignes de CSV à parser.
Votre IA (Claude, ChatGPT, Le Chat…) ne connaît pas la France : seule, elle reformule ce qu'elle a lu, sans date ni source. Branchée à Nyambot, elle interroge les données de l'État à la seconde où vous posez la question — et cite ses sources.
▶ L'agent Nyambot complet est en ligne — essayez-le : nyambot.ai
Exemple : votre agent enchaîne
resolve_commune→risques_immobilier→dpe_logementet restitue un verdict argumenté sur un bien en quelques secondes — là où les APIs brutes ne renverraient que des tableaux à interpréter.
🧠 Des réponses, pas des rows. 1 appel = 1 réponse métier exploitable — sans savoir quel dataset ni quelle colonne interroger.
📎 Sourcé, sans hallucination. Chaque réponse porte sa source officielle (date, référence, montant).
🆓 Gratuit, sans clé API pour ce cœur open-source — installation en une ligne via uvx.
📖 Open-source, licence MIT.
Ce package = le cœur open-source keyless (4 outils, en local). Pour la version complète — 21 outils (marché immobilier DVF réel, Légifrance, SIRENE, fiches Service-Public, aides…), réponses answer-ready et sourcées : le connecteur hébergé est en ligne →
https://mcp.nyambot.ai/mcp(OAuth 2.1). Intégration backend / serveur-à-serveur (clés machine) sur demande. Détails plus bas.
En France, des milliards d'euros de droits ne sont pas réclamés chaque année — pas par manque d'éligibilité, mais parce que l'administration est un labyrinthe. Le problème n'a jamais été l'accès à la donnée (elle est publique) : c'est de la comprendre correctement, en contexte, sans se tromper. C'est exactement le travail que fait la couche d'intelligence de Nyambot — et c'est ce qu'un accès brut aux APIs ne vous donnera jamais.
Nyambot.ai est un agent IA qui ne se contente pas d'informer : il exécute les démarches, ancré sur la donnée officielle de l'État, chaque réponse sourcée, sans hallucination. Là où un chatbot générique invente et où les portails publics n'accompagnent pas, Nyambot agit.
Il couvre tous les cas de vie — carte d'identité, impôts, permis de conduire, carte grise, aides & allocations, déménagement, succession, création d'entreprise, immobilier… nyambot-mcp ouvre une partie de cette capacité à votre propre agent IA.
Sur l'agent complet (nyambot.ai), une question comme « Cette maison à Pierrelatte à 286 000 € est-elle bien placée ? » déclenche une analyse visible étape par étape — l'agent va chercher le fichier DVF, le déroule, et le croise avec les risques et le DPE :
📊 DVF — Demandes de valeurs foncières (data.gouv.fr)
Requête : commune = Pierrelatte (26235) · type = Maison · 2023–2024
→ 38 ventes comparables · médiane du secteur ≈ 2 053 €/m²
⚠️ Géorisques : aléa retrait-gonflement des argiles (moyen)
🏷️ DPE du bien : étiquette AVerdict : à ~2 750 €/m², le bien est ~34 % au-dessus de la médiane locale (source DVF, 38 ventes comparables) — justifiable par le DPE A, mais avec une marge de négociation. Point de vigilance : zone d'aléa argiles à vérifier sur le bâti.
Va chercher la donnée officielle, la déroule, la croise, et cite ses sources — en quelques secondes. Aucun chatbot générique ne fait ça.
La v2 est en ligne. Le connecteur hébergé mcp.nyambot.ai/mcp ouvre l'accès à toute la donnée publique française vivante — démarches administratives, prix de l'immobilier au m² réel (DVF), textes de loi (Légifrance), données d'entreprises (SIRENE) — déjà indexée, citable, prête à l'emploi.
L'accès programmatique à DVF, au RAG des fiches Service-Public et aux sources sémantiques est disponible dès maintenant sur le connecteur hébergé (voir plus bas). Le connecteur gratuit ci-dessous couvre communes, géocodage, risques et DPE — en local, sans clé.
Related MCP server: geocontext
Outil | Ce qu'il fait | Source officielle |
| Nom de commune → code INSEE, département, région, coordonnées, population | geo.api.gouv.fr |
| Adresse → coordonnées, code postal, commune, code INSEE | Base Adresse Nationale |
| Risques naturels & technologiques d'une commune (inondation, argiles, séisme, radon…) | Géorisques |
| DPE des logements existants (étiquette A→G, GES, surface, conso) | ADEME |
Le serveur MCP de data.gouv.fr et nyambot-mcp ne jouent pas au même niveau — ils sont complémentaires :
datagouv-mcp expose le catalogue open-data : on cherche des jeux de données, on liste des ressources, on requête du tabulaire brut. C'est un outil d'exploration / analyste de données.
nyambot-mcp expose des réponses métier prêtes à l'emploi : on pose une question (risques d'une commune, DPE d'un logement…) et on reçoit un résultat exploitable, sans savoir quel dataset ni quelle colonne. C'est un outil de décision.
datagouv-mcp (officiel) | nyambot-mcp | |
Niveau | Catalogue & datasets bruts | Réponses métier curées |
Sources | data.gouv.fr uniquement | Multi-sources : Géorisques, BAN, geo.api.gouv.fr, ADEME… (API natives, hors catalogue data.gouv) |
L'agent doit… | trouver le dataset, deviner les colonnes, construire la requête | …juste appeler l'outil |
Cas d'usage type | « trouve-moi des datasets sur X » | « ce bien est-il à risque ? quel est son DPE ? » |
Fiabilité | dépend du schéma deviné | pré-câblé : 1 appel = 1 réponse |
Vous pouvez brancher les deux. datagouv-mcp pour explorer n'importe quel dataset ; nyambot-mcp pour des réponses rapides sur les cas de vie à forte valeur (immobilier, droits…). Le connecteur hébergé (
mcp.nyambot.ai/mcp, en ligne) ajoute l'interprétation propriétaire : RAG des fiches Service-Public, article Légifrance exact, marché DVF réel, réponses entièrement sourcées.
uv installé (recommandé). Sinon, voir « Depuis les sources » plus bas.
Ajoutez ceci à votre claude_desktop_config.json :
{
"mcpServers": {
"nyambot": {
"command": "uvx",
"args": ["nyambot-mcp"]
}
}
}Puis redémarrez Claude Desktop. uvx télécharge et lance le serveur automatiquement — rien d'autre à installer.
Dans le .mcp.json à la racine de votre projet :
{
"mcpServers": {
"nyambot": { "command": "uvx", "args": ["nyambot-mcp"] }
}
}Ou en une commande :
claude mcp add nyambot -- uvx nyambot-mcpMême bloc mcpServers que ci-dessus, dans la configuration MCP de votre éditeur.
{
"mcpServers": {
"nyambot": {
"command": "uvx",
"args": ["--from", "git+https://github.com/GabMJ23/nyambot-mcp", "nyambot-mcp"]
}
}
}Une fois branché, demandez à votre agent :
« Quel est le code INSEE de Combs-la-Ville ? »
« Quels sont les risques naturels à Pierrelatte avant d'acheter ? »
« Donne-moi des DPE autour du 75011. »
« J'envisage d'acheter au 8 boulevard du Port à Amiens — géocode l'adresse et liste les risques de la commune. »
Exemple de réponse réelle — risques_immobilier("Pierrelatte"), via le connecteur gratuit :
Risques recensés pour Pierrelatte (INSEE 26235) :
- Effet toxique
- Inondation
- Mouvement de terrain
- Nucléaire
- Risque industriel
- Séisme
- Transport de marchandises dangereusesClaude Code : claude mcp list (statut connected) ou /mcp dans une session.
Mode debug pour voir les appels passer : claude --debug.
git clone https://github.com/GabMJ23/nyambot-mcp
cd nyambot-mcp
uv venv && uv pip install -e ".[dev]"
# Lancer les tests (offline, sans réseau)
pytest
# Lancer le serveur localement
nyambot-mcpnyambot-mcp est la partie gratuite et open-source : un connecteur qui appelle directement les API publiques de l'État, sans clé, en local (4 outils : communes, géocodage, risques, DPE).
Le connecteur hébergé — https://mcp.nyambot.ai/mcp, en ligne — fédère 21 outils answer-ready sur l'administration française, y compris ceux qui nécessitent des sources sémantiques et de l'infrastructure hébergée (non self-hostables) :
🏠 Marché immobilier DVF réel — médiane €/m² sur transactions réellement actées
⚖️ Légifrance — l'article de loi exact, texte à jour
💼 SIRENE / INSEE (vérification d'entreprise), Annuaire Santé (ANS), France Travail
📚 RAG des fiches Service-Public (recherche sémantique)
✍️ Génération de courriers administratifs, simulation d'aides
…et plus — le tout en réponses structurées et entièrement sourcées.
Comment y accéder :
Usage interactif (agent piloté par un humain — Claude, ChatGPT, Cursor…) : pointez votre client sur https://mcp.nyambot.ai/mcp. Connexion OAuth 2.1 (PKCE) gérée, elle s'ouvre au 1ᵉʳ appel.
Intégration backend / serveur-à-serveur : clés machine (OAuth client credentials) provisionnées sur demande — on vous fournit un client_id + client_secret, vous obtenez un token et appelez le connecteur en Bearer.
Sous le capot (la plateforme hébergée) :
Construit sur Claude (Anthropic), avec un routage multi-modèles (Haiku / Sonnet) selon la tâche.
Recherche hybride (dense + lexicale) sur un corpus souverain (fiches Service-Public, codes en vigueur, catalogue data.gouv).
Contrat answer-ready : 1 appel = 1 réponse sourcée, avec dégradation honnête (jamais d'erreur qui casse votre agent).
Stack technique (plateforme hébergée) :
Python 3.12 · FastAPI · MCP SDK (Streamable HTTP) · Anthropic SDK · PostgreSQL + pgvector (recherche vectorielle) · embeddings bge-m3 souverains · FTS Postgres (recherche lexicale) · SSE (streaming temps réel) · OAuth 2.1 (PKCE + client credentials) · Alembic (migrations) · Pydantic · httpx · déployé sur Railway (UE).
Le connecteur open-source de ce dépôt reste volontairement minimal (
Python+mcp+httpx) : toute l'infrastructure d'intelligence ci-dessus vit sur la plateforme hébergée.
Le connecteur local restera open-source et gratuit ; les capacités hébergées passent par le backend (OAuth / clé machine).
Vous voulez brancher le connecteur hébergé ou une clé machine backend ? Écrivez-moi (voir Contact ci-dessous).
Questions, retours, demande de clé API v2, ou partenariat :
Gabriel Mbenda — AI Builder & Founder, Nyambot.ai 📧 gabrielmbenda48@gmail.com
MIT © 2026 Gabriel Mbenda — un projet Nyambot.ai.
Les données proviennent des sources officielles du gouvernement français (licence Etalab ouverte). Nyambot est un service indépendant, non affilié à l'État.
mcp-name: io.github.GabMJ23/nyambot-mcp
Diagnostics de Performance Énergétique (DPE) de logements existants (ADEME).
Renvoie étiquette énergie (A→G), étiquette GES, surface, consommation et date du diagnostic. Filtre par code postal, affinable par une adresse.
Args: code_postal: code postal sur 5 chiffres (ex. « 75011 »). adresse: optionnel — texte d'adresse pour affiner (ex. « 48 rue de Montreuil »).
| Name | Required | Description | Default |
|---|---|---|---|
| adresse | No | ||
| code_postal | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses output fields and source (ADEME) but lacks details on behavior such as error handling, rate limits, or authentication needs. For a read-only query tool, the description is adequate but not rich.
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 with four lines plus an Args section that reiterates parameters with examples. Every sentence adds value, though the Args section partially duplicates schema info. Overall well-structured and front-loaded.
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?
Tool has only two parameters and an output schema (present but not shown). Description explains key return fields. For its simplicity, coverage is good; lacks only minor details like error conditions or pagination.
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 0%, so description compensates by explaining both parameters: code_postal as 5-digit zip code with example, adresse as optional text to refine. Adds meaningful context beyond the schema's type and default values.
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?
Description clearly states it returns DPE diagnostics with specific output fields (energy label, GES label, surface, consumption, date) and filtering by postal code and optionally address. This verb+resource definition distinguishes it from sibling tools like geocode_address or risques_immobilier.
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?
Description implies usage context by mentioning filtering by postal code and address, but does not explicitly state when to use this tool versus alternatives, nor provides exclusions or prerequisites. Sibling tools differ in function but no comparative guidance given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Géocode une adresse française via la Base Adresse Nationale (BAN).
Renvoie l'adresse normalisée, les coordonnées, le code postal, la commune et le code INSEE — utile pour cibler ensuite risques/DPE à l'adresse exacte.
Args: adresse: adresse libre (ex. « 8 boulevard du Port, Amiens »).
| Name | Required | Description | Default |
|---|---|---|---|
| adresse | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes return values but does not mention authentication, rate limits, error handling, or behavior for invalid addresses. For a read-only tool, basic transparency is adequate but could be improved.
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, using a short paragraph plus a structured docstring for parameters. Every sentence adds value, with no unnecessary 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 no annotations, one required parameter, and an output schema (present but not shown), the description covers key aspects: purpose, return values, and parameter usage. Lacks error handling details but is sufficient for a simple 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?
The description includes a docstring for the 'adresse' parameter with an example ('8 boulevard du Port, Amiens'). Despite 0% schema coverage, this compensates well by explaining the parameter meaning and format.
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 French address using BAN and returns normalized address, coordinates, postal code, commune, and INSEE code. It distinguishes from siblings like dpe_logement, resolve_commune, and risques_immobilier by specifying its utility for targeting risks/DPE at the exact address.
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 usage when geocoding French addresses but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. No guidance on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Résout une commune française par son nom.
Renvoie code INSEE, département, région, coordonnées et population. À utiliser en PREMIER, comme ancre géographique, avant les autres outils (le code INSEE sert ensuite à interroger les risques, par exemple).
Args: nom: nom de la commune (ex. « Lyon », « Combs-la-Ville »).
| Name | Required | Description | Default |
|---|---|---|---|
| nom | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the lookup behavior and return fields, but does not mention failure modes, rate limits, or authorization. Adequate but not rich.
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 plus a parameter list. Front-loaded with purpose, no wasted words. Efficient and well-structured.
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?
With output schema present, description does not need to detail return values. Covers purpose, usage, and parameter adequately for a simple lookup tool. Slight lack of error handling info, but acceptable.
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 0% description coverage, but the description provides an example ('Lyon', 'Combs-la-Ville') and clarifies the parameter is a commune name. Adds meaningful context beyond the raw 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?
Description clearly states 'Résout une commune française par son nom' (verb+resource) and lists returned fields (code INSEE, département, etc.). It also distinguishes from siblings by positioning itself as the geographic anchor to use first.
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 'À utiliser en PREMIER, comme ancre géographique, avant les autres outils' and gives example of using code INSEE for risks. Provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Risques naturels & technologiques d'une commune (Géorisques / Gaspar).
Couvre inondation, retrait-gonflement des argiles, séisme, radon, mouvements de terrain, sites industriels (ICPE)… À consulter AVANT un achat immobilier.
Accepte un code INSEE (5 chiffres) OU une adresse libre — dans ce dernier cas l'adresse est géocodée automatiquement pour retrouver la commune.
Args: adresse_ou_code_insee: ex. « 69123 » ou « 12 rue de la Paris, Pierrelatte ».
| Name | Required | Description | Default |
|---|---|---|---|
| adresse_ou_code_insee | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses that free addresses are automatically geocoded to identify the commune, a key behavioral trait. It does not mention error handling or response format, but this is partially covered by the output schema.
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 well-structured with bullet points and clear sections, but includes slightly redundant phrasing. Every sentence adds value, so it is efficient but not ultra-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?
Covers input, purpose, and a behavioral nuance (geocoding). With an output schema present, it does not need to explain return values. Could mention whether multiple risks are aggregated, but overall complete for a risk-inspection 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?
With 0% schema coverage, the description adds essential meaning: explains the parameter accepts either an INSEE code or free address, provides concrete examples, and clarifies the geocoding behavior. This fully compensates for the schema's lack of detail.
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 provides natural and technological risks for a French commune, listing specific hazards (inondation, retrait-gonflement, séisme, etc.) and distinguishing it from siblings like dpe_logement, geocode_address, and resolve_commune.
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 advises consulting before a real estate purchase and explains acceptable inputs (INSEE code or free address). However, it does not explicitly mention when not to use the tool or suggest alternatives.
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.
v0.1.1dpe_logementgeocode_addressresolve_communerisques_immobilierScored across 4 tools
Each tool targets a distinct aspect of French real estate: DPE for energy performance, geocoding for address coordinates, commune resolution for geographic anchor, and risks for natural/technological hazards. No overlap in functionality.
Tool names mix French and English inconsistently (e.g., 'dpe_logement' vs 'geocode_address'), and follow different patterns (noun_noun for French, verb_noun for English). This lacks a unified naming convention.
With 4 tools covering the essential use cases for French real estate research—geocoding, commune lookup, DPE, and risks—the count is well-scoped and not excessive.
The tool set covers the main pre-purchase investigation steps: locate, identify commune, check DPE, assess risks. Missing maybe property tax or school info, but core workflow is complete.
Données immobilières officielles françaises (DVF+, cadastre, DPE, risques, urbanisme) via MCP.
MCP server for Japan geodata: cadastral lot numbers (chiban) and reverse geocoding, for AI agents.
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
