Skip to main content
Glama
pwnera

Simulateurs FR

Prime d'activité

prime_activite
Read-onlyIdempotent

Estimate monthly French prime d’activité from net income and household composition, including couple status, children, housing situation, and other resources.

Instructions

Estime la prime d'activité mensuelle selon les revenus d'activité et la composition du foyer.

Input Schema

NameRequiredDescriptionDefault
coupleNo
logementNo
nbEnfantsNo
nbPersonnesNoCompatibilité : nombre de personnes du foyer.
aideLogementNoMontant de l'aide au logement perçue (forfait logement = min(aide, forfait)).
revenusConjointNoRevenus professionnels nets mensuels du conjoint.
revenusMensuelsYesRevenus professionnels nets mensuels (personne 1). En compatibilité : revenus du foyer.
autresRessourcesNoAutres ressources mensuelles (chômage, pensions, allocations familiales…).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is clear. The description adds that this is an estimate based on income and household composition, but it does not clarify whether the result is an official simulation, what assumptions are used, or whether eligibility is checked.

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?

The description is a single front-loaded sentence with no filler or repetition. It is appropriately concise, though for an eight-parameter calculator it leaves useful context to the schema rather than using a second sentence to clarify scope.

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

Completeness2/5

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

For an eight-parameter benefit simulation with no output schema, the description is too sparse: it does not explain the optional versus required inputs, the compatibility fields, or the estimation assumptions. The schema and annotations provide some support, but the description does not fill the remaining contextual gaps.

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?

The description broadly maps to revenusMensuels and the household-composition fields through "revenus d'activité" and "composition du foyer." With 63% schema description coverage, the schema already documents several parameters, but the description does not explain logement enum values, aideLogement, revenusConjoint, or autresRessources.

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 names a specific verb and resource: "Estime la prime d'activité mensuelle." It also scopes the estimate by income and household composition, making the tool identifiable, but it does not differentiate it from sibling financial simulators such as allocation_chomage or simulation_apl.

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 tool name and the phrase "selon les revenus d'activité et la composition du foyer," so an agent can infer when to use it. However, the description gives no explicit when-to-use guidance, no exclusions, and no comparison with sibling benefit calculators.

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