Summary: This MCP server lets an AI assistant query ~1.3 million French building permits (Sitadel) plus surrounding real-estate, urbanism and risk data to evaluate development/«marchand de biens» opportunities.
Search permits (search_permits) by department, commune, permit type, status, dates, minimum land area, requester SIREN, sort and pagination.
Fuzzy address search (fuzzy_search_addresses) to find a permit from an approximate street/city name, accent- and typo-tolerant.
Full permit details (get_permit_details): address, applicant, dates, surfaces, cadastral parcel, lat/lng.
360° view (get_permit_full_view): details + SIRENE + DVF + score + PLU + risks in one call.
Opportunity scoring (get_mdb_score): 0–100 score with tier and weighted-signal breakdown.
Neighbouring property sales (find_dvf_neighbors): recent DVF transactions around a permit to estimate local land value.
PLU zoning (get_plu_zoning): urbanism zone with a constructibility verdict and legal reason.
Natural/technological risks (get_risks): flood, earthquake, clay, nearby ICPE with aggregate score.
Cadastral geometry (get_parcelle_geometry): exact parcel GeoJSON polygon and measured area.
Existing buildings (get_existing_buildings): tells whether a parcel is bare or already built (key value-add signal).
Bulk enrichment (bulk_enrich_list): cross up to 1,000 rows (lat/lng, address or cadastral ref) with permits, score, risks, zoning and parcel data.
Note: the live schema exposes 12 tools (the README advertises 18, including DVF/PLU helpers and advanced MDB scoring v0.3 with 11 signals), and some features are gated by subscription plan.
Serveur MCP (Model Context Protocol) pour PermisAPI.
Il permet à Claude, ChatGPT, Claude Desktop, Cursor, Windsurf ou tout client compatible MCP d'interroger en langage naturel 1,3 million de permis de construire en France (base Sitadel, permis autorisés depuis 2013, 101 départements, logements et locaux).
18 outils en lecture seule : recherche par critères ou par adresse, score d'opportunité marchand de biens v0.3 et son explication (les 11 signaux pondérés, commentés en français), ventes immobilières voisines (DVF, ventes de 2021 à 2025) et prix au m², zonage PLU, risques Géorisques (inondation, séisme, sites Seveso proches…), parcelle cadastrale DGFiP, bâtiments existants (terrain nu ou déjà bâti), parcelles voisines, recherche dans un polygone GeoJSON (ZAC, périmètre d'opération), statistiques de densité par commune, budget de chantier estimé et entreprises du bâtiment proches (base SIRENE, codes NAF 41, 42 et 43), enrichissement d'une liste.
Adresse : https://mcp.permisapi.fr/mcp
Claude et ChatGPT : ajoutez un connecteur personnalisé à cette adresse. Une page PermisAPI s'ouvre ; collez-y votre clé (ou créez-y un compte Gratuit) et cliquez sur Autoriser (OAuth avec PKCE : l'assistant reçoit un jeton, jamais votre clé). Les intitulés des menus changent d'une version à l'autre : le pas à pas à jour est sur permisapi.fr/mcp.
Cursor, Windsurf et autres clients acceptant un en-tête (~/.cursor/mcp.json) :
{
"mcpServers": {
"permisapi-hosted": {
"url": "https://mcp.permisapi.fr/mcp",
"headers": { "Authorization": "Bearer pk_live_VOTRE_CLE" }
}
}
}Transports : Streamable HTTP (spécification MCP actuelle) sur /mcp et /mcp/, et SSE
historique sur /sse + /messages/. Le serveur ne conserve ni vos questions ni les
résultats : il relaie vos appels vers api.permisapi.fr. Quand la mesure d'audience est
activée sur le serveur (PostHog, hébergement UE), chaque appel d'outil y est compté (nom
de l'outil, durée, statut, formule).
Pour Claude Desktop, ou si vous préférez tout faire tourner sur votre machine, installez
le paquet permisapi-mcp.
Related MCP server: Dilix MCP
Python 3.10 ou plus récent (exigé par le SDK MCP)
Une clé PermisAPI : permisapi.fr/#pricing (formule Gratuit, sans carte bancaire)
Vérifiez d'abord la version de Python :
python --version # macOS / Linux / WindowsSi elle est >= 3.10 :
pip install permisapi-mcpSinon, voir Dépannage plus bas (solution uvx en une commande, sans
changer le Python du système).
Modifiez ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) ou
%APPDATA%\Claude\claude_desktop_config.json (Windows) :
{
"mcpServers": {
"permisapi": {
"command": "permisapi-mcp",
"env": {
"PERMISAPI_KEY": "pk_live_VOTRE_CLE"
}
}
}
}Redémarrez Claude Desktop. Vous pouvez alors demander :
« Liste les permis de logement autorisés à Paris ce mois-ci »
« Trouve des permis autour de la rue de Passy à Paris »
« Quel est le zonage PLU du permis 07510125V0025 ? » (formule Régional et plus)
Périmètre géographique selon la formule (src/services/plan_gating.py) :
Gratuit : 1 département, les nouveaux permis des 2 dernières publications Sitadel (environ 2 mois), 500 requêtes par mois.
Découverte : 1 département, 6 mois d'historique, 2 000 requêtes par mois.
Explorateur : 5 départements, 12 mois d'historique, 5 000 requêtes par mois.
Régional : 5 départements, historique complet et données avancées (ventes DVF, score, PLU, risques, cadastre, budget, entreprises).
Pro : les mêmes données avancées sur la France entière.
Business et Entreprise : France entière, plus la recherche par polygone, la densité par commune et l'enrichissement de liste.
Pour les formules à départements (Gratuit, Découverte, Explorateur, Régional), chaque nouveau département interrogé s'ajoute à votre périmètre jusqu'à la limite de la formule ; le choix est ensuite définitif pour cette formule. Les exemples ci-dessus portent sur Paris (75).
Guide complet : permisapi.fr/mcp
Outil | Route | Formules |
| GET /v1/permits (12 filtres et un tri) | Toutes |
| GET /v1/permits/{num_pa} | Toutes |
| GET /v1/search?q=texte (recherche approchée) | Toutes |
| GET /v1/permits/{num_pa}/dvf (ventes DVF 2021-2025, prix médian au m²) | Régional et plus |
| GET /v1/permits/{num_pa}/score (score v0.3, 11 signaux) | Régional et plus |
| GET /v1/permits/{num_pa}/score/explain (11 signaux commentés, principaux leviers) | Régional et plus |
| GET /v1/permits/{num_pa}/plu | Régional et plus |
| GET /v1/permits/{num_pa}/risks (Géorisques) | Régional et plus |
| GET /v1/permits/{num_pa}/parcelle (cadastre DGFiP) | Régional et plus |
| GET /v1/permits/{num_pa}/batiments-existants (terrain nu ou bâti) | Régional et plus |
| GET /v1/parcelles/{id_parcelle} (identifiant cadastral de 14 caractères) | Régional et plus |
| GET /v1/permits/{num_pa}/parcelles-voisines (rayon de 10 à 2 000 m) | Régional et plus |
| GET /v1/permits/{num_pa}/360 (vue complète en un appel) | Régional et plus (détail seul en Gratuit, Découverte et Explorateur) |
| GET /v1/permits/{num_pa}/economics (budget de chantier : fourchette, scénario, lots) | Régional et plus |
| GET /v1/permits/{num_pa}/contractors (entreprises du bâtiment proches, par métier) | Régional et plus |
| POST /v1/permits/inside-polygon (polygone GeoJSON) | Business et Entreprise |
| GET /v1/stats/commune/{code}/density (parcelles, bâtiments, permis) | Business et Entreprise |
| POST /v1/permits/bulk-enrich (liste de 1 000 lignes au plus) | Business et Entreprise |
« Régional et plus » = Régional, Pro, Business et Entreprise. Les autres formules reçoivent une erreur 402.
En mode local, la clé reste sur votre machine (variable d'environnement) ; en mode hébergé, l'assistant ne reçoit qu'un jeton. Dans les deux cas, le modèle ne voit jamais la clé, seulement les arguments des outils.
Validation stricte des entrées (num_pa, identifiants cadastraux, codes INSEE, bornes
numériques).
16 outils en consultation (GET) et 2 en POST (bulk_enrich_list, qui croise une liste
que vous fournissez, et search_permits_in_polygon, qui reçoit un polygone). Tous sont
en lecture seule : ils ne modifient ni votre compte ni les données.
pip install permisapi-mcp répond « package introuvable » ou « no matching distribution »Cause la plus fréquente : votre Python est antérieur à 3.10, minimum exigé par le SDK MCP.
Vérifiez :
python --version # ou python3 --versionSi elle est < 3.10, deux solutions au choix.
Solution A (recommandée, 30 secondes) : uvx avec une version de Python imposée
uvx installe et lance le serveur dans un Python isolé, à la version voulue, sans toucher
à votre installation.
# 1. Installer uv (une seule fois)
curl -LsSf https://astral.sh/uv/install.sh | sh # macOS / Linux
powershell -c "irm https://astral.sh/uv/install.ps1 | iex" # Windows PowerShell
# 2. Lancer le serveur
uvx --python 3.11 permisapi-mcpPuis, dans la configuration de Claude Desktop, remplacez "command": "permisapi-mcp"
par :
{
"mcpServers": {
"permisapi": {
"command": "uvx",
"args": ["--python", "3.11", "permisapi-mcp"],
"env": { "PERMISAPI_KEY": "pk_live_VOTRE_CLE" }
}
}
}Solution B : mettre à jour le Python du système
macOS : brew install python@3.11
Windows : télécharger https://www.python.org/downloads/ et cocher « Add to PATH »
Linux : sudo apt install python3.11 (ou l'équivalent de votre distribution)
Puis pip3.11 install permisapi-mcp.
Guide complet et autres questions : permisapi.fr/mcp
MIT pour le code. Données publiques : SDES (Sitadel), DGFiP (DVF, cadastre), Géorisques, IGN (Géoportail de l'Urbanisme), INSEE (SIRENE).
Croisez une liste fournie par l'utilisateur (max 1000 lignes) avec les permis de France pour recuperer en 1 appel : permis a proximite + score d'opportunité + risques + zonage + parcelle cadastre. Plan Business+ uniquement, coût = 1 unité quota par ligne. Use case : enrichir une liste prospects/patrimoine. 3 modes par ligne : (lat+lng) ou (adresse) ou (commune+section+numero). Le champ 'ref' identifié chaque ligne dans la response.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | ||
| radius_m | No | ||
| max_matches | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses constraints (max 1000 rows, cost per line, plan requirement) and the three input modes, but does not state whether the operation is read-only or has side effects, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of four sentences, directly stating the purpose, constraints, use case, and input modes. It is concise and front-loaded, with no redundant information, though a bulleted list could improve readability.
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 (3 parameters, no output schema, no annotations), the description covers inputs and constraints but does not detail the output structure or how to interpret the results. It mentions the types of returned data but lacks specificity, leaving agents potentially uncertain about the response format.
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 schema has 0% description coverage, so the description must compensate. It explains the three input modes for rows and the role of 'ref'. However, it does not describe 'radius_m' and 'max_matches' beyond what the schema provides (defaults and limits), missing an opportunity to clarify their semantic impact.
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 cross-references a user-provided list with French permits to retrieve multiple data points (proximity permits, opportunity score, risks, zoning, cadastre). It specifies the max list size, use case, and distinguishes from sibling tools that focus on single aspects.
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 identifies the use case (enriching prospect/asset lists) and explains input modes. However, it does not explicitly tell when not to use this tool or mention alternative tools for specific data types, though the context of sibling tools implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pour un permis, retourne les top transactions immobilieres DVF voisines (5 ans glissants). Permet d'estimer la valeur fonciere du quartier. Plan Pro+ uniquement.
| Name | Required | Description | Default |
|---|---|---|---|
| num_pa | Yes | ||
| limit | No | ||
| type_local | No | CSV des types : 1=Maison, 2=Appartement, 3=Dependance, 4=Local commercial. | |
| min_year | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the rolling window and access restriction, but omits behavior details such as what 'top' means, whether permits must exist, output format, or data freshness.
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 front-loaded with action. The second sentence adds value by explaining the purpose, and the third states an important restriction. No waste.
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 4 parameters, no output schema, and no annotations, the description is too minimal. It does not explain what the tool returns, the meaning of 'top,' or how parameters like limit and min_year affect results.
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 only 25% (type_local has a description). The description adds no meaning for limit or min_year, and only implies that num_pa is a permit number. It fails to compensate for the 75% schema coverage gap.
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 top neighboring DVF transactions for a permit, with a rolling 5-year window, and explains its purpose for property value estimation. However, it lacks explicit differentiation from sibling tools like get_permit_details.
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 only mentions a plan restriction (Plan Pro+ uniquement) but provides no guidance on when to use this tool versus alternatives like search_permits or get_existing_buildings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche fuzzy par texte libre sur les adresses (rue, ville, lieudit). Utilise pg_trgm côté DB : insensible aux accents et à la casse, tolérant aux typos. Idéal pour trouver un permis quand on connaît l'adresse approximative mais pas le code postal ou commune INSEE précis. Tous plans (avec respect du scope géo). Coût 1 unité quota. Exemple : 'rue victor hugo paris', 'cours de l ile bordeaux'.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Texte libre a chercher (min 2 chars). | |
| dep_code | No | Restreindre a un département spécifique (ex '75'). | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses technical behavior (pg_trgm, case/accent/typo insensitivity), cost (1 quota unit), and geo scope respect. However, it omits whether the operation is read-only (though implied), what the response contains, or pagination details. The disclosed info is useful but incomplete.
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 (few sentences) with a clear front-loaded purpose. Every sentence adds value: purpose, technical details, use case, cost, example. No fluff or repetition.
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 lack of output schema, the description covers tool purpose, behavior, use case, cost, and geo-scoping. It lacks a description of the return format or error behavior, which would be helpful. Overall, it is mostly complete for a search 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 coverage is 67% (2/3 params have descriptions). The description adds value beyond schema for q by clarifying fuzzy, insensitive, typo-tolerant behavior and giving examples. For dep_code, schema description is sufficient; description adds nothing. For limit, neither schema nor description provides explanation, so a gap remains.
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 a specific verb+resource: 'Recherche fuzzy par texte libre sur les adresses'. It defines the scope (street, city, lieudit) and gives a concrete use case (finding permits via approximate address). The examples further clarify intent, distinguishing it from sibling tools like search_permits.
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 clear context by stating 'Idéal pour trouver un permis quand on connaît l'adresse approximative mais pas le code postal ou commune INSEE précis'. This tells when to use it, but it does not explicitly mention when not to or name alternative siblings. The guidance is helpful but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liste les bâtiments cadastraux déjà construits sur la parcelle du permit. Use case CRITIQUE marchand de biens : distinguer parcelle nue (vraie construction neuve, value-add max) vs parcelle bâtie (extension/rénovation, value-add moindre). Retourne nb_batiments total + décompte par type (bâti dur / bâti léger / autre) + flag parcelle_nue boolean + détails individuels (id Etalab, type label FR, centroïde, dates création/MAJ cadastre). Source : cadastre.data.gouv.fr via Etalab (DGFiP). Plan Pro+ uniquement. Coût 1 unité quota. 404 si le permit n'a pas de polygone cadastre disponible (rare, ~15% des permits).
| Name | Required | Description | Default |
|---|---|---|---|
| num_pa | Yes | Identifiant Sitadel unique (ex PC07404021K1). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It discloses the output (nb_batiments, breakdown, flag, details), data source, plan restriction (Pro+), cost (1 unit), and error behavior (404). It does not mention mutation or safety, but as a read tool, this is sufficient.
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 moderately long but each sentence provides distinct value (purpose, use case, output details, source, limitations, error). It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains the return values, including counts, flag, and individual details. It also covers source, plan restriction, cost, and error case, making it complete for agent invocation.
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% for the single parameter 'num_pa', which is already described in the schema as 'Identifiant Sitadel unique'. The description adds no additional semantic details beyond the schema, so 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 explicitly states the tool lists existing buildings on a parcel for a permit, with specific verb 'Liste' and resource 'bâtiments cadastraux déjà construits'. It distinguishes from siblings by detailing a critical use case (marchand de biens) and output specifics.
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 clear context for when to use the tool (e.g., assessing if a parcel is bare or built) and mentions a specific use case. However, it does not explicitly state when not to use or name alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calcule le Score Opportunité Marchand de Biens v0.1 pour un permis (note 0-100 + tier low/medium/high/premium + breakdown de 7 signaux ponderes). Plan Pro+ uniquement.
| Name | Required | Description | Default |
|---|---|---|---|
| num_pa | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It describes the output (score, tier, breakdown) but does not disclose side effects, prerequisites (beyond plan), error conditions, or whether the operation is read-only. The description gives moderate behavioral context but lacks completeness.
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 one concise sentence, front-loaded with the main action and output. It avoids redundancy but could be slightly better structured with separate lines for output and condition.
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 output schema and one parameter, the description provides key output details but omits what the '7 signaux' are, how errors are handled, and any dependencies (e.g., permit must exist). It is adequate but not fully complete.
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 0%, so the description must compensate. It mentions the parameter is for a permit ('pour un permis') but does not explain the parameter name (num_pa), format, or example. Minimal additional meaning 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 calculates a specific score (Score Opportunité Marchand de Biens v0.1) for a permit, with output details (0-100, tier, breakdown). It also identifies the plan restriction, distinguishing it from sibling tools like get_permit_details or search_permits.
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 states 'Plan Pro+ uniquement', providing a clear condition for use. However, it does not mention when not to use this tool or suggest alternatives, though the plan restriction itself guides appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Géométrie précise de la parcelle cadastre DGFiP du permis (via Etalab open data). Retourne un GeoJSON Polygon WGS84 + surface mesurée en m2 + identifiant Etalab. Permet de visualiser le polygon exact de la parcelle sur une carte (vs juste le point lat/lng adresse). Plan Pro+ uniquement. 404 si la commune n'est pas encore en cache (rare, hors couverture Etalab DOM très récents).
| Name | Required | Description | Default |
|---|---|---|---|
| num_pa | Yes | Identifiant Sitadel unique (ex PC07404021K1). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return format, data source, access restriction, and error condition (404). No annotations provided, so description covers key behavioral traits adequately.
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?
Extremely concise: 2-3 sentences covering purpose, output, usage context, and error. No fluff, front-loaded with main output.
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 simple one-parameter tool with no output schema, the description covers what is returned, data source, error condition, and access. Lacks mention of response size or rate limits 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?
The only parameter has a clear description in the schema; the tool description adds no further semantic detail beyond what's already there. Baseline 3 for high schema coverage.
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 that it returns precise geometry of the cadastre parcel as GeoJSON Polygon with surface area and Etalab ID. It distinguishes from siblings by contrasting with address-based lat/lng.
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?
Mentions the tool is for 'Plan Pro+ uniquement' and a specific 404 case, implying when to use and limitations. Could be more explicit about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recupere tous les détails d'un permis a partir de son identifiant Sitadel (num_pa) : adresse complète, demandeur, dates, surface, parcelle cadastre, lat/lng. Plan Free OK.
| Name | Required | Description | Default |
|---|---|---|---|
| num_pa | Yes | Identifiant Sitadel unique (ex PC07404021K1). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It does not mention error handling, rate limits, authentication, or behavior on invalid input, and only vaguely hints at cost with 'Plan Free OK'.
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 with front-loaded purpose. The first sentence is slightly long but information-dense. No waste.
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 simple single-parameter tool, the description adequately lists the types of details returned. The meaning of 'Plan Free OK' is ambiguous, but overall completeness is sufficient for basic use.
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 clear description of num_pa. The description adds a list of returned fields but does not enhance understanding of the parameter beyond what the schema already provides.
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 retrieves all details of a permit using a specific identifier (num_pa) and lists the types of details returned. It is specific about verb and resource but could better differentiate from sibling get_permit_full_view.
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 guidance on when to use this tool versus siblings like get_permit_full_view or search_permits. The phrase 'Plan Free OK' hints at cost but does not clarify usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vue 360 complète d'un permis en 1 seul appel : détail + sirene + dvf + score MDB + zonage PLU + risques. Le moyen le plus efficace pour analyser un permis quand tu veux tout d'un coup au lieu d'appeler 6 outils séparés. Coût : 6 unités de quota Pro+ (1 par sous-feature, identique à 6 calls séparés). Pour Free / Explorer, retourne uniquement le détail (coût 1 unité). En cas d'échec d'une sous-feature (ex: PLU timeout), le champ vaut null et l'erreur est listée dans fetch_errors. Latence typique 5-7s.
| Name | Required | Description | Default |
|---|---|---|---|
| num_pa | Yes | Identifiant Sitadel unique (ex PC07404021K1). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses cost (6 units for Pro+, 1 for Free/Explorer), failure behavior (null fields, errors in fetch_errors), and typical latency (5-7s).
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 a single paragraph but packs significant detail efficiently. Front-loaded with purpose, though slightly lengthy.
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?
No output schema, so description should explain return values. It lists sub-features but does not detail the JSON structure or fields. Missing structure for a complex combined 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?
Input schema has 100% coverage with description for the single parameter, so baseline 3 applies. The description adds no extra parameter insights beyond what the schema already provides.
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 provides a full 360 view of a permit in one call, combining detail, sirene, dvf, score, zoning, risks. It distinguishes from siblings by explicitly mentioning it replaces 6 separate tools.
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 tells when to use: when you want everything at once instead of 6 separate tools. Also mentions cost implications and plan limitations (Free/Explorer vs Pro+).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retourne le zonage urbanisme PLU au point géocodé du permis (UA/UB urbain, AU a urbaniser, A agricole, N naturelle) avec verdict booleen constructible et raison juridique. Source Geoportail de l'Urbanisme. Plan Pro+ uniquement.
| Name | Required | Description | Default |
|---|---|---|---|
| num_pa | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the output (zoning types, constructible boolean, legal reason) and source, but does not disclose potential side effects, authentication needs, or error handling. The tool is clearly a read-only query, but lacks details on behavior under failure.
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 two sentences: the first delivers the core functionality and output details, the second adds source and restriction. No wasted words, and key information is 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?
For a tool with one parameter, no annotations, and no output schema, the description covers the output structure (zoning types, boolean, reason) and source. It lacks error scenarios or response format specifics, but is mostly complete for a simple query 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 coverage is 0% and the description does not explicitly explain the 'num_pa' parameter. It implies it is the permit number ('au point géocodé du permis'), but no format or example is provided. The description adds minimal value 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 it returns zoning information (PLU) at the geocoded point of the permit, listing specific zoning types (UA/UB, AU, A, N), a boolean constructibility verdict, and legal reason. It distinguishes itself from sibling tools like get_risks or get_existing_buildings by focusing specifically on zoning.
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 limits usage to 'Plan Pro+ uniquement', providing a clear condition for when to use this tool. It does not mention when not to use it or suggest alternatives, but the restriction is helpful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Risques naturels et technologiques (inondation, seisme, argile, ICPE proches) connus sur la commune du permis. Score agrege 0-100 + tier. Source Géorisques BRGM. Plan Pro+ uniquement.
| Name | Required | Description | Default |
|---|---|---|---|
| num_pa | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only mentions the data source (Géorisques BRGM) and a usage restriction. It does not specify that this is a read-only operation, potential rate limits, caching behavior, or what happens if the commune has no data. The aggregate score range is given but tier meaning is unclear.
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 at 25 words but mixes French terms without translation, potentially hindering clarity. It front-loads key information but lacks clear structure (e.g., separate lines for different details). Not verbose but not optimally organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter, no output schema, and no annotations, the description is insufficient. It lacks details on output format (beyond score and tier), error handling, how to interpret the tier, and what happens if the permit number is invalid. Agents may not reliably know how to use the response.
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 schema has one required parameter 'num_pa' (string) with 0% description coverage. The tool description does not explain what 'num_pa' represents (e.g., permit number or parcel identifier), leaving the agent to guess from sibling tools. No additional semantic context is provided.
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 the tool retrieves natural and technological risks (inondation, seisme, argile, ICPE) for the municipality of a permit, including an aggregate score (0-100) and tier. It identifies the specific resource and action, distinguishing it from sibling tools like get_permit_details or get_mdb_score, which cover different 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?
The description mentions 'Plan Pro+ uniquement' (only for Pro+ plan) as a constraint, but lacks explicit guidance on when to use this tool versus alternatives. No instructions on prerequisites, when not to use, or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche des permis de construire de France avec filtres combinables : département, commune, type de permis, état, dates, surface min, SIREN demandeur. Retourne une page de permits avec leurs infos de base. Plan Free OK.
| Name | Required | Description | Default |
|---|---|---|---|
| dep_code | No | Code département INSEE 2 chars (ex 75 Paris, 33 Bordeaux). Requis pour Free/Explorer. | |
| comm_code | No | Code commune INSEE 5 chars (ex 75116 Paris 16e). | |
| permit_type | No | ||
| etat_pa | No | État permis : 1=Accordé, 2=Tacite, 3=Refusé, 4=Irrecevable, 5=Retrait, 6=Achevé. | |
| date_from | No | YYYY-MM-DD. | |
| date_to | No | YYYY-MM-DD. | |
| min_superficie | No | Surface terrain min en m². | |
| siren_dem | No | SIREN du demandeur (9 chiffres). | |
| sort | No | Tri du résultat. Champs autorisés : date_reelle_autorisation, date_depot, an_depot, superficie_terrain. Préfixe '-' pour descendant (ex '-superficie_terrain' pour les plus grandes surfaces en premier). Défaut '-date_reelle_autorisation'. | |
| min_score | No | Filtre les permis avec un Score Opportunité MDB >= N (0-100). Réservé aux plans Pro+. Permet de shortlister les top opportunités en 1 call. Coût quota = `limit` unités (pas 1). | |
| max_risk | No | Filtre les permis dont la commune est au-dessus du tier de risque spécifié (Géorisques BRGM). Exemple 'moderate' retourne uniquement low + moderate. Réservé aux plans Pro+. Coût quota = `limit` unités (pas 1). Use case marchand de biens : exclure d'office les zones inondables / Seveso / sismiques eleves. | |
| plu_zone_type | No | Filtre par prefix de zonage urbanisme PLU. U = urbain constructible, AU = a urbaniser, A = agricole non constructible, N = naturelle non constructible. Réservé aux plans Pro+. Coût quota = limit unites. | |
| plu_constructible | No | Filtre par verdict de constructibilite PLU. true = uniquement zones constructibles (U + AU). false = uniquement zones non constructibles (A + N). Réservé aux plans Pro+. Coût quota = limit unites. Combine avec min_score pour shortlister les vraies opportunités MDB. | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that certain filters have quota costs and are reserved for higher plans, which is good. However, it lacks details on pagination, error responses, or rate limits, and doesn't clarify that 'page' implies no offset parameter (only limit).
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 tight sentences, front-loaded with purpose. The first sentence lists filters efficiently. Could be structured with bullet points for readability, but overall no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 complex parameters, no output schema, and no annotations, description covers plan tiers, cost implications, and return type ('page de permits'). Missing details: pagination mechanism, return field list, error handling, and rate limits. However, sibling tools like get_permit_details fill the gap for detailed views, making this adequate for a search endpoint.
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 86% (12 of 14 params have descriptions), so baseline is 3. The description adds minimal value beyond schema: it states 'filtres combinables' and 'infos de base', but doesn't elaborate on parameter usage or constraints beyond what's in 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 it searches for French building permits with combinable filters and returns basic info. The verb 'Recherche' and resource 'permis de construire' are specific. While it distinguishes from siblings like get_permit_details by its listing nature, it doesn't explicitly contrast with them.
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 for filtered searches but provides no explicit when-to-use or alternatives. It mentions plan restrictions (e.g., 'Free OK', 'réservé aux plans Pro+') which gives some context, but no guidance on when to choose this over sibling tools like bulk_enrich_list or find_dvf_neighbors.
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.5.0bulk_enrich_listfind_dvf_neighborsfuzzy_search_addressesget_existing_buildingsget_mdb_scoreget_parcelle_geometryget_permit_detailsget_permit_full_viewget_plu_zoningget_riskssearch_permitsScored across 11 tools
Each tool targets a distinct aspect of permit data: search, details, full view, geometry, buildings, DVF, zoning, risks, merchant score, bulk enrichment, and address lookup. No overlap in functionality.
Tools follow a consistent verb_noun pattern in snake_case, mostly using 'get_' or 'search_', with one 'find_' and one 'fuzzy_search_' as minor deviations. Overall predictable and descriptive.
11 tools is well-scoped for the domain of building permit analysis, covering search, details, and various enrichment analyses without being excessive.
The tool set provides comprehensive coverage for permit analysis: search, details, full view, parcel geometry, existing buildings, DVF, zoning, risks, merchant score, bulk enrichment, and address fuzzy search. No obvious gaps for a read-only API.
Données immobilières officielles françaises (DVF+, cadastre, DPE, risques, urbanisme) via MCP.
French public-data MCP: cross-ref health, demographics, business, geo & real-estate.
French real estate data: cadastre, DVF sales, DPE energy ratings, price estimates, parcel context
US parcels and building permits from public sources. No owner data. Pay per record or monthly plan.
