Skip to main content
Glama

tax-retirement

by io.github.herve-coulon
OverviewDiscussionsAdmin

fiscal_per_gain

Read-onlyIdempotent

Gain d'impôt d'un versement PER — Économie d'impôt TOTALE d'un versement PER déductible = Δ(IR au barème + CEHR + CDHR). Le versement réduit le RFR ; pour un foyer plafonné par la CDHR le gain marginal réel est ≈ 20 % (PAS la TMI) → recalcul complet, jamais TMI × versement. Version stateless. Pour le montant maximal déductible (plafond) → fiscal_per_plafond. (sources: CGI art. 163 quatervicies (déductibilité PER) ; CGI art. 197 (barème/décote) ; CGI art. 223 sexies (CEHR) ; CGI art. 224 (CDHR))

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
partsNoParts de quotient familial.
situationNoSituation familiale.Célibataire
versementYesVersement PER déductible envisagé (€).
parent_isoleNoParent isolé (case T, art. 194 II CGI) : célibataire ou divorcé vivant seul avec au moins un enfant à charge. La part du 1er enfant est alors plafonnée à 4 262 € (art. 197 I-2) au lieu de 2 × 1 807 €. Les parts transmises doivent déjà inclure la demi-part case T.
demi_parts_195_abeNoDemi-parts de l'art. 195-1 a, b ou e CGI (personne vivant seule ayant élevé seule un enfant 5 ans, enfant décédé, enfant adopté) incluses dans les parts : plafonnées à 1 079 € chacune.
residence_alterneeNoAvec parent_isole : enfants UNIQUEMENT en résidence alternée — la demi-part de chacun des deux premiers enfants est plafonnée à 2 131 € (art. 197 I-2 CGI). Les parts transmises doivent inclure les majorations de 0,25 (art. 194 I).
nb_personnes_chargeNoPersonnes à charge (majoration CDHR).
demi_parts_invaliditeNoDemi-parts d'invalidité ou d'ancien combattant (art. 195-1 c, d, d bis, f et 195-2 à 6 CGI) incluses dans les parts : plafond de droit commun + réduction de 1 801 € chacune quand le plafonnement joue.
revenus_financiers_pfuNoRevenus financiers au PFU inclus dans le RFR (€) — pour le calcul CDHR.
revenu_fiscal_referenceYesRFR du foyer AVANT versement (€).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / demi_parts_195_abe
      Added value: +{
+  "default": 0,
+  "description": "Demi-parts de l'art. 195-1 a, b ou e CGI (personne vivant seule ayant élevé seule un enfant 5 ans, enfant décédé, enfant adopté) incluses dans les parts : plafonnées à 1 079 € chacune.",
+  "minimum": 0,
+  "type": "number"
+}
    • addedInput schema / properties / demi_parts_invalidite
      Added value: +{
+  "default": 0,
+  "description": "Demi-parts d'invalidité ou d'ancien combattant (art. 195-1 c, d, d bis, f et 195-2 à 6 CGI) incluses dans les parts : plafond de droit commun + réduction de 1 801 € chacune quand le plafonnement joue.",
+  "minimum": 0,
+  "type": "number"
+}
    • addedInput schema / properties / parent_isole
      Added value: +{
+  "default": false,
+  "description": "Parent isolé (case T, art. 194 II CGI) : célibataire ou divorcé vivant seul avec au moins un enfant à charge. La part du 1er enfant est alors plafonnée à 4 262 € (art. 197 I-2) au lieu de 2 × 1 807 €. Les parts transmises doivent déjà inclure la demi-part case T.",
+  "type": "boolean"
+}
    • addedInput schema / properties / residence_alternee
      Added value: +{
+  "default": false,
+  "description": "Avec parent_isole : enfants UNIQUEMENT en résidence alternée — la demi-part de chacun des deux premiers enfants est plafonnée à 2 131 € (art. 197 I-2 CGI). Les parts transmises doivent inclure les majorations de 0,25 (art. 194 I).",
+  "type": "boolean"
+}
  2. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already establish readOnly/idempotent/openWorld=false, so the safety profile is covered; the description goes further by disclosing the internal method (full recalculation, not TMI × versement) and that it is the stateless version. It stops short of stating boundary behavior, e.g. whether a versement above the deductible ceiling is clamped or errors out.

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 the core computation and the anti-pattern warning (never TMI × versement) before the routing hint and source list. Dense and somewhat run-on, and the legal-source tail is long, but every clause carries domain value rather than 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 10-parameter, no-output-schema tool in a complex tax domain, the description covers what is computed and how, plus the sibling boundary. It omits what the response actually looks like (a euro amount, presumably) since no output schema exists to carry that, and does not say how the many optional parameters influence the result.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema itself is unusually detailed (per-parameter legal citations, plafonds, case T handling), so the description's job here is minimal. It adds the note that the payment reduces the RFR, but no syntax, units or constraint information beyond what the schema already supplies.

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 computed quantity (tax gain from a deductible PER payment) and even gives the formula it implements, Δ(IR barème + CEHR + CDHR). It explicitly distinguishes itself from the closest sibling, fiscal_per_plafond, so an agent can route between them without opening either schema.

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?

Names the alternative tool (fiscal_per_plafond) and the exact condition that selects it (when the user wants the maximum deductible amount rather than the tax gain). It also flags the case where the naive approach misleads (CDHR-capped households where marginal gain is ~20% rather than the TMI).

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

All tax-retirement 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