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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "acheter_louer"
  }
}

Input 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. Changed2 schema fields changed
    • addedInput schema / properties / credit / properties / quotite_totale / description
      Added value: +"Quotité totale couverte par taux_assurance : 1 pour une personne à 100 %, 2 pour un couple assuré chacun à 100 %."
    • changedInput schema / properties / credit / properties / taux_assurance / description
      Previous value: -"Taux d'assurance du crédit, lorsqu'il est fourni. La quotité d'un couple est une entrée distincte."New value: +"Taux annuel d'assurance du crédit, avec quotite_totale. Sans quotite_totale, la quotité est demandée et rien n'est calculé."
  2. 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."
  3. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already establish the pure-computation profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real substance: it names the default sources (Livret A, Banque de France rate and duration, estimated notary fees, constant prices and rents, hypothesesVersion/hypotheses) and warns that any result resting on a default is indicative. It also discloses a behavioural quirk the schema does not — the response may carry up to two clarifying questions (a_demander) and deliberately contains no decision field. Only return formatting and failure behaviour are left unstated.

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 inputs, then default provenance, then output contract and caveats — a logical order for a 21-parameter tool, and no sentence is filler. It is dense and long, but the length is justified by the absence of an output schema; the run-on enumeration of input names is the only slightly wasteful part.

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 complex simulator with no output schema, the description supplies what's needed: input/default contract, the output anatomy (écart year by year, point_mort, four cost blocks, hors_assurance, a_demander, grille) and the indicative-result caveat. Left open are units/currency, what exactly the 'grille' contains beyond the +1%/+2% price scenarios, and how a_demander questions are surfaced to the caller.

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?

With 21 parameters and 57% schema description coverage, the description does meaningful work: it groups the key inputs (prix, apport, loyer_annuel, crédit, frais, département, date d'acte, charges, horizon, hypothèses d'évolution) and, more usefully, states the substitution rule for omitted values — rates and duration from Banque de France, notary fees estimated, prices and rents held constant, apport yield at the Livret A rate. Secondary parameters (travaux, taxe_fonciere_annuelle, charges_locatives_annuelles, patrimoine_immobilier_taxable) are only covered by the schema.

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: 'Compare, dans le temps, le patrimoine d'un acheteur de résidence principale et celui d'un locataire'. The scope (French primary residence, buy-vs-rent, wealth path over time) is unambiguous and separates it from the simulate_immo_* siblings (foreign property) and the compare_* siblings.

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?

Usage is implied by the framing rather than stated: an agent can infer the tool is for a buy-vs-rent arbitrage, and the closing sentences ('un résultat qui repose sur une hypothèse par défaut est indicatif', 'ne contient pas de champ de décision') tell it how to interpret the output. But no alternative is named and no when-not condition is given, so the agent must decide alone whether this beats compare_chemin or marcel_compare_scenarios.

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.