Instant pricing for French land-registry documents (etat hypothecaire, deeds). Read-only, no auth.
Scored across 5 tools
Most tools are clearly distinct (devis vs. abonnements vs. guide search), but the two orientation tools overlap: hel-orienter-commande returns service page URLs while hel-orienter-service returns profession-based page URLs, both producing URLs with no calculation. The two pricing tools (hel-devis-public for a service quote vs. hel-tarifs-abonnements for the subscription grid) could also be confused for a generic 'how much does it cost' query, though descriptions do help.
All names share a consistent 'hel-' prefix and kebab-case formatting, which is predictable. The verb/noun style is mostly verb_noun (orienter-commande, orienter-service, rechercher-guide), with two noun-only names (devis-public, tarifs-abonnements) as minor deviations.
Five read-only tools is well-scoped for an informational/orientation assistant covering quotes, subscriptions, guides, and page routing. Each tool earns its place with no redundancy padding the set.
The surface covers the apparent domain well: service pricing, subscription pricing, editorial guide search, and orientation to service/profession/order pages. Actual ordering and payment happen on the site (explicitly out of scope), so the only minor gap is the absence of any tool reconciling the two orientation paths.
Donne le prix d'un service Hypothèques en ligne : tarif public (prix_ht) et tarifs par niveau d'abonnement (Essentiel, Privilège, Intégral). Montants hors TVA, débours inclus (les débours ne sont pas soumis à la TVA). Lecture seule, sans authentification ni donnée personnelle. État hypothécaire (ehf) : précisez type_recherche et le nombre de parcelles, de lots ou de personnes ; sans ces précisions, le devis suppose une recherche cadastrale sur 1 parcelle. Débours : 12 € par élément recherché (7 € en Alsace-Moselle aux niveaux Privilège et Intégral). Un état hypothécaire couvre 1 parcelle et 1 personne au tarif public et au niveau Essentiel, jusqu'à 5 parcelles et 3 personnes (8 éléments) au niveau Privilège, jusqu'à 12 parcelles et 3 personnes (15 éléments) au niveau Intégral ; au-delà, plusieurs états sont facturés. Situation de patrimoine (situation_patrimoine) : le prix dépend de la zone couverte — un département (patrimoine_dept, ou le code postal de localisation_bien), une région (patrimoine_region) ou la France entière (patrimoine_zone = france) ; non disponible en Alsace-Moselle ni dans la région Grand Est.
| Name | Required | Description | Default |
|---|---|---|---|
| nb_lots | No | EHF en copropriété : nombre de lots. | |
| service | Yes | Code du service : ehf (état hypothécaire), acte (copie d'acte notarié), rcp (règlement de copropriété), edd (état descriptif de division), verif_mandat (vérification de mandat), pre_etat_date, pack_propriete, pack_rcp, pack_edd, rdv_analyste (rendez-vous analyste), analyse_ia (analyse d'état hypothécaire par IA), situation_patrimoine (situation de patrimoine immobilier), recherche_proprietaire (recherche des coordonnées du propriétaire). | |
| copropriete | No | EHF : true si le bien est en copropriété (on compte les lots au lieu des parcelles). | |
| nb_parcelles | No | EHF, recherche cadastrale ou combinee : nombre de parcelles. | |
| nb_personnes | No | EHF, recherche identite ou combinee : nombre de personnes physiques et morales. | |
| type_combinee | No | EHF, requis si type_recherche = combinee. ciblee = recherche à l'intersection (débours forfait 12 € + 2 € par élément au-delà de 5). | |
| type_recherche | No | EHF uniquement : cadastrale = par parcelles (ou par lots si copropriété) ; identite = par personnes ; combinee = les deux. | |
| patrimoine_dept | No | situation_patrimoine, zone departement : numéro du département (ex. "34", "2A", "971"), son nom ou un code postal. | |
| patrimoine_zone | No | situation_patrimoine : zone couverte. Facultatif si patrimoine_dept, patrimoine_region ou un code postal est fourni. | |
| proprio_inconnu | No | recherche_proprietaire : true si le propriétaire est inconnu (supplément). | |
| localisation_bien | No | Commune avec code postal (ex. "34000 Montpellier"). Non requise pour le tarif public d'un état hypothécaire (identique partout). Recommandée pour les packs (règle Alsace-Moselle des abonnés). Pour situation_patrimoine, son code postal suffit à désigner le département. | |
| patrimoine_region | No | situation_patrimoine, zone region : nom de la région. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/openWorldHint/non-destructive, but the description adds genuinely extra traits: no authentication and no personal data required, a default assumption (a cadastral search on 1 parcelle when no counts are supplied) that changes the returned price, coverage ceilings per subscription level, and an availability restriction (situation_patrimoine unavailable in Alsace-Moselle/Grand Est).
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?
Purpose is front-loaded in the first clause, and every following sentence carries pricing or scoping information rather than filler. It is dense and reads as a wall of text, but for a quote-calculation tool the detail is largely load-bearing.
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 12 parameters, 5 enums and an output schema (so return values need no explanation), the description covers the two complex services (ehf, situation_patrimoine) thoroughly, including defaults, ceilings and exclusions. It does not touch the simpler fixed-price services (acte, rcp, edd, packs), which is a minor gap.
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 baseline is 3, but the description goes further by explaining how parameters combine to determine price: the default 1-parcelle assumption, the per-element débours rates (12 €/7 €), and the zone logic linking patrimoine_dept/patrimoine_region/patrimoine_zone and localisation_bien's postal code to situation_patrimoine pricing.
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?
States a specific verb and resource ('Donne le prix d'un service Hypothèques en ligne') and names the exact outputs (tarif public prix_ht, tarifs par niveau d'abonnement). It is unambiguous what the tool returns, but it never differentiates itself from the sibling hel-tarifs-abonnements, which also concerns subscription-level pricing, so an agent could confuse the two.
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?
Usage is implied by the purpose (call it to obtain a quote) and the description adds useful context on default assumptions for ehf, but it never states when to choose this over hel-orienter-service, hel-orienter-commande or especially hel-tarifs-abonnements, nor any exclusion conditions for the tool itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fournit les LIENS de page d'un service HEL : 'page_service_url' (page de présentation du service) et 'commande_directe_url' (formulaire de commande). N'effectue aucun calcul et ne renvoie aucun montant : pour un prix ou un devis chiffré, ce n'est pas cet outil. Services pris en charge : état hypothécaire, copie d'acte de vente, situation de patrimoine, règlement de copropriété, état descriptif de division, pré-état daté, packs, recherche de coordonnées propriétaire, vérification de mandat, RDV analyste, analyse IA, recherche de référence cadastrale. URL officielles exactes ; le paiement se fait sur le site.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | Service / document souhaité (texte libre). Ex. : état hypothécaire, copie d'acte, situation de patrimoine, règlement de copropriété, état descriptif de division, pré-état daté, pack propriété, pack règlement copropriété, pack EDD, recherche coordonnées propriétaire, vérification de mandat, RDV analyste, analyse IA, référence cadastrale. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value beyond annotations by disclosing that the tool performs no calculation, returns no amounts, supplies exact official URLs, and that payment happens on the external site—clarifying what the tool does and does not do. No contradiction with 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?
The description is front-loaded with purpose, then the exclusion clause, then the service list, then URL/payment details. It is longer than minimal, but the extended service catalog is justified given openWorldHint=true and a free-text parameter. Every sentence earns its place.
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 an output schema present to document return values and only one simple parameter, the description covers the essential operational facts: returned fields, supported services, exclusions, and payment behavior. The only notable gap is the missing explicit relationship to the hel-orienter-service sibling.
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 the single 'service' parameter is already documented with examples. The description reinforces this by enumerating the full supported service catalog in free text, adding meaningful scope context for an open-world parameter beyond what the schema examples provide.
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 a specific action (provides page links: page_service_url and commande_directe_url) and enumerates the supported service catalog. It clearly distinguishes itself from pricing/quote tools ('ne renvoie aucun montant'). However, it does not differentiate from the near-twin sibling hel-orienter-service, which likely returns the same presentation-page link, leaving potential ambiguity.
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 an explicit exclusion clause ('pour un prix ou un devis chiffré, ce n'est pas cet outil') that routes agents away from pricing use cases toward quote/rate siblings. However, it never names the alternatives nor clarifies when to choose this tool over hel-orienter-service versus hel-devis-public, leaving the primary routing decision implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
À partir de la profession du prospect (avocat, banque, courtier, syndic, agent ou agence immobilière, commissaire de justice / huissier, assurance, géomètre-expert, énergies renouvelables / solaire / éolien, marchand de biens, promoteur), renvoie l'URL de la page de service HEL consacrée à cette profession (présentation, tarifs, abonnement et commande). Pour un particulier ou une profession non listée, renvoie la page des tarifs professionnels. N'effectue aucun calcul et ne renvoie aucun montant ; le paiement se fait sur le site.
| Name | Required | Description | Default |
|---|---|---|---|
| profession | Yes | Profession du prospect (texte libre). Valeurs typiques : Agents immobiliers, Assurances, Avocats, Banques & Courtiers, Commissaires de justice, Énergies renouvelables, Géomètres-experts, Marchands de biens, Promoteurs & autres, Syndics, Autre/particulier. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint and destructivenes=false, so the safety profile is covered. The description goes further and adds genuinely new behavior: no calculation is performed, no amount is returned, and payment happens externally on the site – which prevents the agent from expecting a price. No rate limits or resolution/precondition details are given, but the added context is substantive.
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 key behavior (returns the service-page URL) is front-loaded, and the two closing sentences are tight and high-value. But the opening sentence embeds a long parenthetical list of thirteen professions that the input schema already enumerates, adding length without new 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?
With an output schema present, return values need not be described, and annotations cover the safety profile, so the remaining burden is light. The description covers the input interpretation, the fallback branch and the no-payment behavior. The only gap is explicit disambiguation from the four similarly named sibling tools.
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 baseline is 3, and the profession enumeration in the description largely duplicates the schema's 'Valeurs typiques' list. What it adds is the interpretation rule for unmatched free-text input: an individual or unlisted profession is routed to the professional pricing page, which is real semantic guidance on how the parameter is resolved.
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 gives a specific verb and resource: it takes a prospect's profession and returns the URL of the corresponding HEL service page. It even enumerates the supported professions and the fallback (particulier/non listée → page tarifs professionnels). It never names or contrasts a sibling tool, so an agent must infer the boundary with hel-tarifs-abonnements or hel-orienter-commande on its own.
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?
Clear context for use: when you have a prospect's profession and need the matching service page. It also handles the edge case (particulier or unlisted profession → professional pricing page), which is effectively a when-to-use branch. However, no alternative tool is ever named, so the routing decision against the four sibling tools is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche dans les guides et la FAQ d'Hypothèques en ligne (plusieurs centaines d'articles en droit immobilier français, rédigés par l'équipe et sourcés sur les textes officiels) et renvoie, pour chaque guide pertinent, son titre, son résumé « En bref » et son adresse. Sujets couverts : hypothèque (définition, durée, mainlevée, hypothèque judiciaire), état hypothécaire (contenu, lecture, utilité avant un achat ou une vente), service de la publicité foncière et fichier immobilier, cadastre et références cadastrales, identification du propriétaire d'un bien, copropriété (règlement, état descriptif de division, pré-état daté), successions, saisies et ventes aux enchères immobilières. Utile pour répondre à une question de définition ou de démarche sur ces sujets en citant une source. Ne calcule aucun prix. Lecture seule, sans donnée personnelle.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | La question de l'utilisateur, ou quelques mots-clés (ex. « mainlevée d'hypothèque », « lire un état hypothécaire », « pré-état daté »). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, destructiveHint=false, openWorldHint), and the description adds real context: corpus scale, sourcing from official texts, per-result return shape (titre, résumé « En bref », adresse), and the no-personal-data / no-price constraints. It does not discuss ranking, result limits, or empty-result behavior.
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?
Purpose and coverage are front-loaded, and every clause is informative for retrieval selection. The long enumeration of subject areas is slightly dense but earns its place by clarifying the corpus boundary.
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?
An output schema exists, so return values need no further explanation, and the description nonetheless confirms the per-guide fields. Corpus scope, usage context, and the read-only/no-price boundaries make it fully sufficient for correct 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?
There is a single parameter with 100% schema description coverage, so the schema already carries the semantics including keyword examples. The description restates the topical scope but adds no query syntax or format guidance beyond the schema's baseline.
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?
It states a specific verb (Recherche) and resource (guides et FAQ d'Hypothèques en ligne) and enumerates the covered subject domains, so the agent knows exactly what corpus is searched. The closing constraints ('Ne calcule aucun prix', 'Lecture seule') also implicitly separate it from the pricing/quote siblings.
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?
It explicitly says it is 'Utile pour répondre à une question de définition ou de démarche sur ces sujets en citant une source', which is a clear when-to-use condition. It does not name a sibling alternative or state exclusions beyond the implicit 'Ne calcule aucun prix'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Renvoie la grille des tarifs d'abonnement HEL (mensuel et annuel HT, conditions d'engagement) par niveau : Public, Essentiel, Privilège, Intégral. Aucun paramètre. Lecture seule, sans authentification ni donnée personnelle. Répond aux questions sur le coût des abonnements sans devis de service.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations, the description adds that the call requires no authentication and involves no personal data. A low-risk, static lookup tool, but the extra behavioral context is useful.
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 short sentences deliver purpose, content, scope, and usage conditions. No filler or repetition beyond the necessary explicit statement that there are no parameters.
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 parameterless read-only pricing tool, this covers what is returned, the granularity (monthly/annual, excl. tax), the tiers, authentication expectations, and the boundary against quote requests. No meaningful gap remains.
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 zero parameters. The description explicitly states 'Aucun paramètre', which is appropriate and avoids any illusion of inputs needing to be supplied.
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?
Uses a specific verb and resource ('Renvoie la grille des tarifs'), lists the exact tiers, and states the price dimensions (mensuel et annuel HT). It clearly distinguishes itself from quote/order tools by noting it is not a service quote.
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?
Gives a clear usage context: answering subscription-cost questions without producing a service quote. It does not explicitly name the sibling tool for quotes, but the exclusion is sufficient guidance for routing.
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.
hel-devis-public20 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / copropriete / descriptionPrevious value: -"EHF : true si le bien est en copropriété (on dénombre les lots au lieu des parcelles)."New value: +"EHF : true si le bien est en copropriété (on compte les lots au lieu des parcelles)."Input schema / properties / localisation_bien / descriptionPrevious value: -"Commune avec code postal (ex. \"34000 Montpellier\"). NON requise pour le tarif public d'un état hypothécaire : le prix public est identique partout. Requise pour les packs et situation_patrimoine ; pour les abonnés, elle affine les débours en Alsace-Moselle."New value: +"Commune avec code postal (ex. \"34000 Montpellier\"). Non requise pour le tarif public d'un état hypothécaire (identique partout). Recommandée pour les packs (règle Alsace-Moselle des abonnés). Pour situation_patrimoine, son code postal suffit à désigner le département."Input schema / properties / nb_lots / descriptionPrevious value: -"EHF en copropriété : nombre de lots (max 12)."New value: +"EHF en copropriété : nombre de lots."Input schema / properties / nb_lots / maximumAdded value: +100Input schema / properties / nb_lots / minimumAdded value: +1Input schema / properties / nb_parcelles / descriptionPrevious value: -"EHF, recherche cadastrale/combinee : nombre de parcelles (max 12)."New value: +"EHF, recherche cadastrale ou combinee : nombre de parcelles."Input schema / properties / nb_parcelles / maximumAdded value: +100Input schema / properties / nb_parcelles / minimumAdded value: +1Input schema / properties / nb_personnes / descriptionPrevious value: -"EHF, recherche identite/combinee : nombre de personnes physiques + morales (max 3)."New value: +"EHF, recherche identite ou combinee : nombre de personnes physiques et morales."Input schema / properties / nb_personnes / maximumAdded value: +30Input schema / properties / nb_personnes / minimumAdded value: +1Input schema / properties / patrimoine_deptAdded value: +{
+ "description": "situation_patrimoine, zone departement : numéro du département (ex. \"34\", \"2A\", \"971\"), son nom ou un code postal.",
+ "type": "string"
+}Input schema / properties / patrimoine_regionAdded value: +{
+ "description": "situation_patrimoine, zone region : nom de la région.",
+ "enum": [
+ "Auvergne-Rhône-Alpes",
+ "Bourgogne-Franche-Comté",
+ "Bretagne",
+ "Centre-Val de Loire",
+ "Corse",
+ "Guadeloupe",
+ "Guyane",
+ "Hauts-de-France",
+ "Île-de-France",
+ "La Réunion",
+ "Martinique",
+ "Normandie",
+ "Nouvelle-Aquitaine",
+ "Occitanie",
+ "Pays de la Loire",
+ "Provence-Alpes-Côte d'Azur"
+ ],
+ "type": "string"
+}Input schema / properties / patrimoine_zoneAdded value: +{
+ "description": "situation_patrimoine : zone couverte. Facultatif si patrimoine_dept, patrimoine_region ou un code postal est fourni.",
+ "enum": [
+ "departement",
+ "region",
+ "france"
+ ],
+ "type": "string"
+}Input schema / properties / proprio_inconnuAdded value: +{
+ "description": "recherche_proprietaire : true si le propriétaire est inconnu (supplément).",
+ "type": "boolean"
+}Input schema / properties / service / descriptionPrevious value: -"Service HEL : ehf, acte, rcp, edd, verif_mandat, pre_etat_date, pack_propriete, pack_rcp, pack_edd, rdv_analyste, analyse_ia, situation_patrimoine, recherche_proprietaire."New value: +"Code du service : ehf (état hypothécaire), acte (copie d'acte notarié), rcp (règlement de copropriété), edd (état descriptif de division), verif_mandat (vérification de mandat), pre_etat_date, pack_propriete, pack_rcp, pack_edd, rdv_analyste (rendez-vous analyste), analyse_ia (analyse d'état hypothécaire par IA), situation_patrimoine (situation de patrimoine immobilier), recherche_proprietaire (recherche des coordonnées du propriétaire)."Input schema / properties / service / enumAdded value: +[
+ "ehf",
+ "acte",
+ "rcp",
+ "edd",
+ "verif_mandat",
+ "pre_etat_date",
+ "pack_propriete",
+ "pack_rcp",
+ "pack_edd",
+ "rdv_analyste",
+ "analyse_ia",
+ "situation_patrimoine",
+ "recherche_proprietaire"
+]Input schema / properties / type_combinee / descriptionPrevious value: -"EHF, requis si type_recherche=combinee. ciblee = recherche à l'intersection (débours forfait 12€ + 2€/élément au-delà de 5)."New value: +"EHF, requis si type_recherche = combinee. ciblee = recherche à l'intersection (débours forfait 12 € + 2 € par élément au-delà de 5)."Input schema / properties / type_recherche / descriptionPrevious value: -"EHF uniquement : base de la recherche au SPF. cadastrale = par parcelles (ou lots si copropriété) ; identite = par personnes ; combinee = les deux."New value: +"EHF uniquement : cadastrale = par parcelles (ou par lots si copropriété) ; identite = par personnes ; combinee = les deux."hel-rechercher-guidehel-devis-public2 fields changedOutput schema / descriptionAdded value: +"Prix public (prix_ht) du service ; tarifs réduits par niveau d'abonné dans abonnement.prix_par_niveau_ht."Output schema / propertiesAdded value: +{}hel-orienter-commande3 fields changedInput schema / additionalPropertiesAdded value: +falseOutput schema / descriptionAdded value: +"service_detecte, intitule, page_service_url, commande_directe_url."Output schema / propertiesAdded value: +{}hel-orienter-service3 fields changedInput schema / additionalPropertiesAdded value: +falseOutput schema / descriptionAdded value: +"Page de service adaptée : profession_detectee, intitule, url."Output schema / propertiesAdded value: +{}hel-tarifs-abonnements4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / propertiesAdded value: +{}Output schema / descriptionAdded value: +"Grille d'abonnements par niveau : mensuel_ht, annuel_ht, engagement + note TVA."Output schema / propertiesAdded value: +{}hel-devis-public2 fields changedOutput schema / descriptionRemoved value: -"Prix public (prix_ht) du service ; tarifs réduits par niveau d'abonné dans abonnement.prix_par_niveau_ht."Output schema / propertiesRemoved value: -{}hel-orienter-commande3 fields changedInput schema / additionalPropertiesRemoved value: -falseOutput schema / descriptionRemoved value: -"service_detecte, intitule, page_service_url, commande_directe_url."Output schema / propertiesRemoved value: -{}hel-orienter-service3 fields changedInput schema / additionalPropertiesRemoved value: -falseOutput schema / descriptionRemoved value: -"Page de service adaptée : profession_detectee, intitule, url."Output schema / propertiesRemoved value: -{}hel-tarifs-abonnements4 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / propertiesRemoved value: -{}Output schema / descriptionRemoved value: -"Grille d'abonnements par niveau : mensuel_ht, annuel_ht, engagement + note TVA."Output schema / propertiesRemoved value: -{}hel-devis-public2 fields changedOutput schema / descriptionAdded value: +"Prix public (prix_ht) du service ; tarifs réduits par niveau d'abonné dans abonnement.prix_par_niveau_ht."Output schema / propertiesAdded value: +{}hel-orienter-commande3 fields changedInput schema / additionalPropertiesAdded value: +falseOutput schema / descriptionAdded value: +"service_detecte, intitule, page_service_url, commande_directe_url."Output schema / propertiesAdded value: +{}hel-orienter-service3 fields changedInput schema / additionalPropertiesAdded value: +falseOutput schema / descriptionAdded value: +"Page de service adaptée : profession_detectee, intitule, url."Output schema / propertiesAdded value: +{}hel-tarifs-abonnements4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / propertiesAdded value: +{}Output schema / descriptionAdded value: +"Grille d'abonnements par niveau : mensuel_ht, annuel_ht, engagement + note TVA."Output schema / propertiesAdded value: +{}hel-devis-publichel-orienter-commandehel-orienter-servicehel-tarifs-abonnementsFrench real estate data: cadastre, DVF sales, DPE energy ratings, price estimates, parcel context
A French address, all public facts: parcel, zoning, risks, permits, sales, energy labels. No key.
Free, keyless French company checks (Sirene, BODACC, VIES, asset freezes) and DPE rental compliance
Rooftop solar potential, RGE installer search and quote requests. France only, no API key.
Add one secure layer between your agents and this server.
