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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. With no output schema, the description carries the return-shape burden and does so well (current indexation, latest CPI, next indexation date, five years of monthly CPI), plus a non-obvious computational caveat about how the multiplier relates to next_indexation_minimum_multiplier.

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?

Two sentences, front-loaded with the return contents; no filler. The second sentence is dense domain jargon (start index 105.78, threshold) that earns its place as a correctness warning but makes the description somewhat heavy for a read-only status call.

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?

Given a no-argument read-only tool with no output schema, the description fully covers what is returned and adds the one dangerous misinterpretation to avoid. Nothing essential for correct invocation is missing, though it omits any freshness/pagination note about the five-year CPI series.

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% and the single locale parameter is fully documented with enum values and default, so the description correctly adds nothing. Baseline 3 for high coverage with no extra parameter meaning.

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 opens with a specific verb-and-resource statement ("Returns the CPI indexation currently in force") and enumerates exactly what data comes back, including base year and time span. It is clearly differentiated in substance from calculate_rpv and get_rate_table, but never names or contrasts those siblings explicitly, so it stops short of a 5.

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?

Usage is only implied ("call this to see the current indexation situation"); no when/when-not conditions or alternatives are stated. The closing warning ("do not derive it from the current multiplier") is a genuine domain guideline that constrains behavior, which lifts it above a bare 2.

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