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

Beyond the read-only/idempotent/destructive annotations, the description discloses the non-obvious BACEN/IBGE date convention (start month excluded, end month included) and the conditional output behavior with 'valor' and 'incluir_valores'. No contradiction with annotations — 'consulta' matches readOnlyHint=true. It does not address defaults or error behavior, but the core behavioral traits are well covered.

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 dense sentences with no filler. The first sentence front-loads the purpose and the critical date convention; the second adds the conditional invocation modes. Every clause earns its place.

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?

The tool has 6 parameters, no output schema, and moderate complexity. The description covers purpose, date convention, and output modes, and hints at return values. But it leaves pro_rata unexplained, the default behavior when data_final is omitted (it is optional) unstated, and the unusual 'NENHUM' enum value unaddressed — notably, 'retorna o valor corrigido' only describes the value path, not what result shape the base query returns.

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?

With 0% schema description coverage, the description carries the full burden. It enriches most parameters: the date convention defines data_inicial/data_final semantics, 'valor' maps to corrected-value output, and 'incluir_valores' maps to monthly variations. However, pro_rata — a parameter that materially alters how the correction is computed — is left completely undocumented, a meaningful gap at this coverage level.

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 names a specific verb ('Consulta de índice oficial') and resource (accumulated correction factor between two dates), with an exact date convention (initial month excluded, final month included). This clearly differentiates it from the many calculo_* siblings covering aluguel, FGTS, pensão, trabalhista, etc., none of which deal with official price indices.

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 conditional mode guidance — 'Se valor informado, retorna o valor corrigido; se incluir_valores true, retorna as variações mensais' — which tells an agent how to elicit different behaviors. However, it provides no explicit when-to-use vs alternatives or exclusions; the domain is implied by 'índice oficial' rather than contrasted with sibling tools.

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