Skip to main content
Glama
Sign In

Parcellaire — cadastre, DVF & DPE

by re.parcellai
OverviewDiscussionsAdmin

Envoyer un retour à l'équipe Parcellaire

send_feedback
Idempotent

Transmet à l'équipe Parcellaire un retour sur le service, pour orienter ses évolutions : besoin non couvert, donnée manquante, bug, idée de fonctionnalité ou retour positif. N'appeler qu'avec l'accord explicite de l'utilisateur dans la conversation, jamais à son insu : quand il demande lui-même à envoyer un retour (origine 'utilisateur'), ou après lui avoir proposé de signaler une demande que les outils n'ont pas permis de satisfaire (donnée absente, filtre manquant, erreur répétée) et qu'il a accepté (origine 'assistant'). Lui dire ce qui sera envoyé, reformuler fidèlement, ne rien inventer, un seul envoi par besoin. Ne jamais inclure de données personnelles : ni nom, email, téléphone, adresse précise, numéro de parcelle ou de DPE, ni URL d'annonce ; décrire le besoin en termes généraux (commune ou département au plus). L'équipe ne répond pas par ce canal : pour une question ou une réponse personnelle, orienter vers https://parcellai.re/contact.

Input Schema

NameRequiredDescriptionDefault
typeYes'fonctionnalite' (outil, filtre ou usage souhaité), 'donnees_manquantes' (donnée absente, incomplète ou trop ancienne), 'bug' (erreur ou résultat faux), 'positif' (ce qui a été utile), 'autre'
outilsNoNoms des outils Parcellaire appelés pendant la conversation, dans l'ordre, ex: ['find_parcelles_by_address', 'search_ventes_dvf']
profilNoProfil de l'utilisateur, seulement s'il ressort clairement de la conversation : 'acheteur', 'proprietaire' (ou vendeur), 'locataire', 'professionnel_immobilier' (agent, notaire, diagnostiqueur, promoteur, géomètre), 'investisseur', 'collectivite', 'developpeur', 'etude' (presse, recherche, analyse de marché). Omettre sinon.
messageYesLe retour lui-même : ce qui manque, ce qui ne marche pas ou ce qui serait utile, avec le résultat attendu
origineYes'utilisateur' si l'utilisateur a demandé lui-même à envoyer ce retour, 'assistant' si l'IA l'a proposé et que l'utilisateur a accepté
cas_usageYesCe que l'utilisateur cherchait à accomplir, en termes généraux, ex: 'comparer le prix au m² d'une maison avec les ventes récentes du quartier avant une offre d'achat à Nantes'
accord_utilisateurYestrue : l'utilisateur a accepté dans la conversation l'envoi de ce retour. Sans son accord, ne pas appeler l'outil.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / accord_utilisateur
      Added value: +{
+  "const": true,
+  "description": "true : l'utilisateur a accepté dans la conversation l'envoi de ce retour. Sans son accord, ne pas appeler l'outil.",
+  "type": "boolean"
+}
    • changedInput schema / properties / origine / description
      Previous value: -"'utilisateur' si l'utilisateur a demandé à envoyer ce retour, 'assistant' si l'IA le signale d'elle-même"New value: +"'utilisateur' si l'utilisateur a demandé lui-même à envoyer ce retour, 'assistant' si l'IA l'a proposé et que l'utilisateur a accepté"
    • changedInput schema / required
      Previous value: -[
-  "type",
-  "origine",
-  "cas_usage",
-  "message"
-]New value: +[
+  "type",
+  "origine",
+  "accord_utilisateur",
+  "cas_usage",
+  "message"
+]
  2. Added

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover only the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false); the description adds the load-bearing behavioral rules an agent cannot infer: mandatory consent gating, one send per need, faithful reformulation with no invention, and a strict no-personal-data constraint (no name, email, phone, address, parcel or DPE number, listing URL).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then the consent rule, then the privacy rule, then the fallback channel — a logical order. It is dense and long for a single description, but every sentence encodes a distinct rule rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a write tool with a const-true consent parameter and strict privacy requirements, the description supplies everything an agent needs: invocation conditions, content rules, cardinality, and the correct alternative when the tool is the wrong channel. No output schema exists, but the 'no reply from this channel' statement covers the return expectation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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, but the description adds real semantic constraints beyond the schema: how 'origine' should be chosen, that the message must be a faithful reformulation, and that content must stay at commune/department granularity. This meaningfully enriches the documented parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Transmet à l'équipe Parcellaire un retour sur le service') and enumerates the kinds of feedback accepted, so the agent knows exactly what this does. It is trivially distinguishable from all sibling tools, which are read-only data lookups, while this one is an outbound message to the team.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the when: only with the user's explicit consent, either when they ask themselves (origine 'utilisateur') or after the assistant proposed reporting an unmet need that was accepted (origine 'assistant'). It also states the when-not ('jamais à son insu') and names the alternative channel (the contact URL) for questions the team cannot answer here.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Parcellaire — cadastre, DVF & DPE toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources