Skip to main content
Glama
Sign In

Marcel

by fr.marcel-retraite
OverviewDiscussionsAdmin

Projeter un profil patrimonial complet

marcel_financial_twin
Read-onlyIdempotent

Ne calcule ni la pension de retraite ni des options de transmission : la pension relève de marcel_estimate_pension ; les options de transmission d'un patrimoine (donation, démembrement, succession, comparaison) d'optimiser_patrimoine ; l'agrégation revenu par source sans chronologie, de marcel_revenue_at_retirement. Pour l'écart avec un objectif seul, voir marcel_find_gap. Calcule la projection chronologique d'un profil déjà paramétré : revenu à la retraite par source, écart avec l'objectif, chronologie et scénarios. Entrées : profil (année de naissance, revenus, pension brute, revenu fiscal de référence d'avis, parts) et actifs (LMNP, résidence principale, PER, assurance-vie). Sortie : revenu par source, écart, chronologie et audit. Le net de pension est chiffré à partir du brut, du revenu fiscal de référence d'avis et des parts, ou d'un net fourni avec sa provenance ; sinon il est null. Calcul non couvert par les jeux de référence Marcel : résultat indicatif.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "profile": "<profile>"
    },
    "name": "marcel_financial_twin"
  }
}

Input Schema

NameRequiredDescriptionDefault
assetsNoActifs patrimoniaux (LMNP, RP, PER, AV). Optionnel.
profileYes
scenarioLabelNoLabel de la simulation pour le snapshot

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the calculation semantics: the net pension is derived from brut + RFR d'avis + parts or taken from a provided net with provenance, otherwise null, and results are flagged as indicative because the calculation is not covered by Marcel reference datasets. That is meaningful context beyond structured fields. It does not describe failure behaviour or what the 'audit' output contains.

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

Conciseness3/5

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

Every sentence carries information, but the structure is inverted: four negative clauses open the description before any positive statement of purpose, which slows selection for an agent. The exclusion block could be compressed into one sentence, and the input/output enumeration partially restates the schema.

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?

There is no output schema and the description enumerates the return fields (revenu par source, écart, chronologie, audit), states the fallback null behaviour for the pension net, and warns that results are indicative. That is adequate for a nested, multi-input projection tool. Only the contents of the 'audit' payload and any sensitivity of results to missing assets remain unspecified.

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 coverage is 67% and the description summarises both required and optional inputs (année de naissance, revenus, pension brute, RFR d'avis, parts; actifs LMNP/RP/PER/AV). It adds meaning beyond the schema by explaining the branch condition for the pension net (derived vs caller-provided with provenance, otherwise null), which links several parameters into one decision. It does not clarify scenarioLabel or the tauxCsgSaisi enum.

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

Purpose4/5

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

The description states a specific verb and resource: 'Calcule la projection chronologique d'un profil déjà paramétré', with enumerated outputs (revenu à la retraite par source, écart, chronologie, scénarios). It is clearly differentiated from marcel_estimate_pension, marcel_find_gap and marcel_revenue_at_retirement. However, the actual purpose statement only appears after four clauses of exclusions, so an agent skimming the first line reads what the tool is not before learning what it does.

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?

Explicit routing: pension → marcel_estimate_pension, transmission options → optimiser_patrimoine, per-source income aggregation without chronology → marcel_revenue_at_retirement, gap-alone → marcel_find_gap. Each exclusion names the alternative, and the positive case (full chronological projection of an already-parameterised profile) is stated, leaving nothing to inference.

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

All Marcel 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