Instant pricing for French land-registry documents (etat hypothecaire, deeds). Read-only, no auth.
Scored across 4 tools
Each tool has a clearly distinct purpose: one for service pricing (devis), one for order links (commande), one for profession-based orientation, and one for subscription tariffs. No overlap or ambiguity.
All tools share the 'hel-' prefix and use French terms, but there is a mix of noun-based names (devis-public, tarifs-abonnements) and verb-based names (orienter-commande, orienter-service). The pattern is not perfectly uniform but is readable and predictable.
With 4 tools, the server is well-scoped for its purpose of providing pricing, links, and orientation for HEL services. Each tool earns its place and the count is neither too thin nor too heavy.
The tool surface covers key user needs: pricing quotes, order links, professional orientation, and subscription tariffs. Minor gaps exist (e.g., a general service overview tool), but agents can work around them using the provided links and information.
Donne le PRIX (coût, tarif, « combien coûte ») d'un service HEL : tarif public et tarifs réduits par niveau d'abonnement (Public, Essentiel, Privilège, Intégral). Lecture seule, sans authentification, sans donnée personnelle. Pour l'état hypothécaire (ehf), le prix total = un honoraire forfaitaire par niveau + des débours refacturés (12€/élément, 7€ en Alsace-Moselle pour Privilège/Intégral) calculés selon type_recherche et le nombre d'éléments. Fournis type_recherche et les nombres (nb_parcelles / nb_lots / nb_personnes) pour un devis EHF exact ; sans eux, seul l'honoraire forfaitaire est estimé (débours non calculés). Plafonds : 12 parcelles, 12 lots, 3 personnes.
| Name | Required | Description | Default |
|---|---|---|---|
| nb_lots | No | EHF en copropriété : nombre de lots (max 12). | |
| service | Yes | 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. | |
| copropriete | No | EHF : true si le bien est en copropriété (on dénombre les lots au lieu des parcelles). | |
| nb_parcelles | No | EHF, recherche cadastrale/combinee : nombre de parcelles (max 12). | |
| nb_personnes | No | EHF, recherche identite/combinee : nombre de personnes physiques + morales (max 3). | |
| type_combinee | No | EHF, requis si type_recherche=combinee. ciblee = recherche à l'intersection (débours forfait 12€ + 2€/élément au-delà de 5). | |
| type_recherche | No | EHF uniquement : base de la recherche au SPF. cadastrale = par parcelles (ou lots si copropriété) ; identite = par personnes ; combinee = les deux. | |
| localisation_bien | No | 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already flag readOnly/openWorld/non-destructive, and the description adds meaningful behavior beyond them: no authentication required, no personal data involved, exact EHF calculation with 12€ débours and the 7€ Alsace-Moselle adjustment, plus hard caps. This is substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The high-value pricing statement is front-loaded and every clause carries information. It loses a point for minor redundancy ('coût, tarif, « combien coûte »') and for packing the EHF rules into a dense paragraph rather than clearer structure.
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?
The description is nearly complete: it gives pricing logic, caps, and the localisation exception, and the output schema presumably covers the response. It does not explicitly address copropriete=true or type_combinee=ciblee in the fee calculation, though the schema documents those fields.
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?
Although schema coverage is 100%, the description enriches the parameters with the fee formula, cap values, and when each count matters. It clarifies that omitting parameters yields only the flat fee estimate and that localisation_bien is not needed for the public EHF price, adding real decision 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 opens with a specific verb and object: 'Donne le PRIX ... d'un service HEL', then clearly distinguishes public pricing from subscription-level pricing. It also explicitly scopes the main special case (EHF), making the tool's purpose unmistakable and easy to separate from the orientation 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 gives actionable usage context: provide type_recherche and the count parameters for an exact EHF quote, otherwise only the flat fee is estimated; localisation_bien is required for packs and situation_patrimoine. It does not explicitly name alternatives such as hel-tarifs-abonnements or state when not to use the tool, so it stops short of a 5.
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 adaptée — où le client découvre le service, souscrit son abonnement et passe commande. Pour un particulier ou une profession non listée, renvoie la page des tarifs professionnels. Renvoie l'URL officielle exacte de la page de service correspondante (présentation, tarifs, souscription et commande). 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?
Les annotations déclarent readOnlyHint, openWorldHint et destructiveHint=false. La description ajoute des précisions utiles : l'outil renvoie une URL officielle exacte, ne traite pas le paiement, et le client est redirigé vers le site pour souscrire ou commander. Aucune contradiction avec les annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
La description est bien structurée : déclencheur, liste des entrées, cas de repli, nature de la sortie. Elle contient une légère redondance avec la répétition de 'renvoie l'URL' et de la notion de page service/tarifs, mais reste concise et l'essentiel est en tête.
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?
Pour un outil à un seul paramètre avec schéma de sortie et annotations, la description est complète : elle couvre les valeurs acceptées, le cas particulier/non listé, la nature exacte de la sortie (URL officielle) et l'absence de traitement du paiement. Un agent dispose de tout ce qui est nécessaire pour appeler correctement l'outil.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Le schéma documente déjà le paramètre `profession` à 100 % avec les valeurs typiques. La description répète ces valeurs et ajoute le comportement de repli pour une profession non listée, mais n'apporte pas de contrainte de format, d'exemple supplémentaire ou de précision syntaxique. Le niveau 3 de référence est donc adapté.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
La description indique clairement le verbe et la ressource : renvoyer l'URL de la page de service HEL adaptée à la profession. Elle liste les professions couvertes et précise le comportement pour les particuliers ou professions non listées. Elle ne différencie toutefois pas explicitement l'outil de ses frères comme hel-tarifs-abonnements ou hel-orienter-commande.
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?
Le contexte d'utilisation est explicite : à partir de la profession, renvoyer la page de service correspondante, avec un basculement clair vers la page des tarifs professionnels pour les particuliers et les professions non listées. Il manque cependant une règle explicite de substitution avec les outils frères, par exemple quand privilégier hel-tarifs-abonnements ou hel-devis-public.
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-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.
Rooftop solar potential, RGE installer search and quote requests. France only, no API key.
Estimation DVF indicative, frais de notaire et rendement locatif, en lecture seule.
Add one secure layer between your agents and this server.
