Skip to main content
Glama

Acheter ou louer sa résidence principale

acheter_louer
Read-onlyIdempotent

Compare, dans le temps, le patrimoine d'un acheteur de résidence principale et celui d'un locataire. Entrées : prix, apport, loyer annuel, et éventuellement crédit, frais, département, date d'acte, charges, horizon et hypothèses d'évolution. Absents, les taux, la durée, les frais de notaire, la résidence principale, l'évolution des prix et des loyers et le rendement de l'apport prennent les valeurs publiées dans hypothesesVersion et hypotheses (Livret A, taux et durée Banque de France, frais de notaire estimés, prix et loyers constants). Sortie : écart de patrimoine année par année, point_mort (énoncé et limite), coûts en quatre blocs (acquisition, financement, détention, sortie), hors_assurance, a_demander (deux questions au plus) et une grille. Un résultat qui repose sur une hypothèse par défaut est indicatif. La réponse ne contient pas de champ de décision.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
prixNo
apportNo
creditNoCaractéristiques du crédit. Absentes : taux et durée Banque de France, inscrits dans hypotheses. L'assurance et la quotité d'un couple restent des entrées lorsqu'elles sont connues.
detailNocompact : sans échéancier du crédit ni lignes par année. complet : avec l'échéancier. Absent : compact.
travauxNo
date_acteNoDate de l'acte au format AAAA-MM-JJ. Avec le département, le barème DGFiP remplace l'estimation des frais.
departementNoCode département, par exemple 75, 2A, ou 69M pour Lyon.
horizon_maxNoHorizon en années. Absent : 30 ans, et la grille est publiée.
frais_entreeNoFrais d'acquisition. Absents, et sans département : estimation publiée par le calcul. null : zéro explicite.
loyer_annuelNo
evolution_prixNoÉvolution annuelle du prix. Absente : 0, avec +1 % et +2 % dans la grille.
frais_de_venteNo
primo_accedantNotrue lorsque l'acheteur est primo-accédant.
evolution_loyerNoÉvolution annuelle du loyer. Absente : loyer constant, inscrit dans hypotheses.
rendement_apportNoRendement annuel de l'apport non investi dans le logement. Absent : taux du Livret A, hypothèse de référence sans risque, avec son plafond dans hypotheses.
charges_annuellesNo
frais_acquisitionNoAssiette des frais d'acquisition pour une plus-value hors résidence principale : forfait, ou reels (égal à frais_entree). Sans effet pour une résidence principale.
taxe_fonciere_annuelleNo
charges_locatives_annuellesNo
patrimoine_immobilier_taxableNo
residence_principale_au_moment_de_la_venteNoRésidence principale au moment de la vente. Absente pour un logement : le calcul retient la résidence principale et l'inscrit dans hypotheses.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changed
    • changedInput schema / properties / credit / description
      Previous value: -"Ne pas le remplir. Le moteur met le taux et la durée Banque de France. L'assurance et la quotité d'un couple restent à fournir."New value: +"Caractéristiques du crédit. Absentes : taux et durée Banque de France, inscrits dans hypotheses. L'assurance et la quotité d'un couple restent des entrées lorsqu'elles sont connues."
    • changedInput schema / properties / credit / properties / assures / items / properties / taux / description
      Previous value: -"Ne pas le supposer. Seulement si la personne le donne, ou si result.question porte sur l'assurance."New value: +"Taux d'assurance de cet assuré, lorsqu'il est fourni."
    • changedInput schema / properties / credit / properties / taux_assurance / description
      Previous value: -"Ne pas le supposer. La quotité d'un couple non plus."New value: +"Taux d'assurance du crédit, lorsqu'il est fourni. La quotité d'un couple est une entrée distincte."
    • changedInput schema / properties / credit / properties / taux_nominal / description
      Previous value: -"Ne pas le remplir : le moteur met le taux Banque de France et l'écrit dans hypotheses."New value: +"Taux nominal annuel du crédit. Absent : taux Banque de France, inscrit dans hypotheses."
    • changedInput schema / properties / date_acte / description
      Previous value: -"Date de l'acte AAAA-MM-JJ, seulement si la personne la donne. Avec le département, le barème DGFiP remplace l'estimation."New value: +"Date de l'acte au format AAAA-MM-JJ. Avec le département, le barème DGFiP remplace l'estimation des frais."
    • changedInput schema / properties / departement / description
      Previous value: -"Code département si la personne le donne : 75, 2A, 69M pour Lyon. Ne pas l'inventer."New value: +"Code département, par exemple 75, 2A, ou 69M pour Lyon."
    • changedInput schema / properties / detail / description
      Previous value: -"Ne pas le remplir. compact par défaut : sans l'échéancier du crédit ni les lignes par année. complet seulement si la personne demande l'échéancier."New value: +"compact : sans échéancier du crédit ni lignes par année. complet : avec l'échéancier. Absent : compact."
    • changedInput schema / properties / evolution_loyer / description
      Previous value: -"Ne pas le remplir. Le moteur met un loyer constant et l'écrit."New value: +"Évolution annuelle du loyer. Absente : loyer constant, inscrit dans hypotheses."
    • changedInput schema / properties / evolution_prix / description
      Previous value: -"Ne pas le remplir. Le moteur met 0 et montre +1 % et +2 % dans la grille."New value: +"Évolution annuelle du prix. Absente : 0, avec +1 % et +2 % dans la grille."
    • changedInput schema / properties / frais_acquisition / description
      Previous value: -"Inutile pour une résidence principale. Hors RP seulement : forfait ou reels (= frais_entree)."New value: +"Assiette des frais d'acquisition pour une plus-value hors résidence principale : forfait, ou reels (égal à frais_entree). Sans effet pour une résidence principale."
    • changedInput schema / properties / frais_entree / description
      Previous value: -"Ne pas l'estimer. Sans département, le moteur publie une estimation. null = zéro explicite."New value: +"Frais d'acquisition. Absents, et sans département : estimation publiée par le calcul. null : zéro explicite."
    • changedInput schema / properties / horizon_max / description
      Previous value: -"Ne pas le choisir. Sans durée, le moteur lit 30 ans et publie la grille."New value: +"Horizon en années. Absent : 30 ans, et la grille est publiée."
    • changedInput schema / properties / primo_accedant / description
      Previous value: -"Ne pas le supposer. true seulement si la personne est primo-accédante."New value: +"true lorsque l'acheteur est primo-accédant."
    • changedInput schema / properties / rendement_apport / description
      Previous value: -"Ne pas le remplir et ne pas proposer 4 %. Le moteur met le taux du Livret A comme référence sans risque, et écrit le plafond."New value: +"Rendement annuel de l'apport non investi dans le logement. Absent : taux du Livret A, hypothèse de référence sans risque, avec son plafond dans hypotheses."
    • changedInput schema / properties / residence_principale_au_moment_de_la_vente / description
      Previous value: -"Ne pas le remplir pour un achat de logement : le moteur suppose la résidence principale et l'écrit."New value: +"Résidence principale au moment de la vente. Absente pour un logement : le calcul retient la résidence principale et l'inscrit dans hypotheses."
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description goes further by disclosing which parameters fall back to published hypotheses (Livret A rate, Banque de France rate/duration, notary fees, constant prices/rents) and by stating the response contains no decision field and only up to two clarifying questions ('a_demander'). That is meaningful behavioral context beyond the annotations.

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?

Purpose is front-loaded, followed by inputs, defaults, output shape, and caveats in a logical order. The single long sentence about defaults is dense but each clause (taux, durée, frais de notaire, évolution) earns its place; there is little filler.

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

Completeness4/5

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

For a 21-parameter tool with no output schema, the description supplies the return structure (year-by-year wealth gap, point_mort, four cost blocks, hors_assurance, a_demander, grid), which the schema cannot convey. It is complete enough to call correctly, though the absence of explicit usage routing leaves one gap.

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?

The description lists the input families (prix, apport, loyer, crédit, frais, département, date d'acte, charges, horizon, hypothèses) and, more importantly, explains the default behavior for omitted values tied to hypothesesVersion/hypotheses. With schema coverage at 57%, the prose compensates for the undocumented parameters, though not exhaustively for all 21.

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?

The opening sentence states a precise verb and resource: comparing the wealth trajectory of a primary-residence buyer versus a renter over time. That object is unambiguous and clearly distinct from the sibling simulation tools (pension, AV, CTO, IFI), so an agent can route here without opening the schema.

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

Usage Guidelines3/5

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

The description defines the input domain and the default-hypothesis behavior, which implies when the tool applies, but it never states when to prefer it over an alternative or names any sibling. It also flags that default-based results are 'indicatif', a useful caveat, yet provides no explicit when-to-use guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.