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

No annotations are provided, so the description carries the full behavioral burden. It compensates well by disclosing the formula, the 2026 service values, the built-in plausibility check, and the source files/versions used. It does not fully specify error behavior or return format, but the sanity check and formula cover the main behavioral expectations.

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

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

The description is compact for the complexity involved and front-loads the core formula and scope. The source references at the end are slightly extra but provide useful traceability, and no part is redundant.

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

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

For a tool with 7 parameters, 28 enum options, no annotations, and no output schema, this description is nearly complete: it defines the computation, scope, exclusions, coefficients, and plausibility control. It could be more explicit about the exact return format or units, but the main invocation requirements are covered.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the computation context for points, coefficient, and regime routing, and by enumerating the accepted regime families, which helps select the correct code_regime enum value.

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

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

The description clearly states the tool's exact function: computing the gross pension of a single points-based regime using a precise formula (points × value 2026 × coefficient). It also lists the regimes covered, which differentiates it from siblings like retraite_estimation and retraite_pension_totale.

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

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

The description gives an explicit routing rule: for annuities/SAM regimes (CNAV) or salaried regimes, use retraite_estimation. It also names the regime families it does cover, so an agent can decide without opening the schema.

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