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

With no annotations provided, the description carries the full burden, and it does a strong job: it discloses the included components (saldo de salário, férias, 13º, aviso prévio, multa FGTS), tax treatment (INSS/IRRF), historical reference_date behavior, TRCT-based twelfths, and notice_worked handling. It does not describe the output shape or rounding behavior, so it is not fully complete.

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?

Four sentences, front-loaded with the tool's purpose, then the calculation scope, then advanced input behavior, then required/optional parameters. Every sentence earns its place, and there is no filler or repeated prose.

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 10-parameter financial calculator with no output schema, the description is largely complete: it explains what is calculated, which parameters matter in special cases, and which names to use. The only notable gap is that it never describes the return format, which matters more here because there is no output schema to fall back on.

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 does not need to redefine parameters. It adds a useful naming warning ('Use exatamente estes nomes, em inglês') and restates required/optional parameters, but it provides little semantic value beyond what the input schema already gives.

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: 'Calcula rescisão trabalhista CLT' and clearly scopes the tool to three termination types: demissão sem justa causa, pedido de demissão, and acordo. It lists the main calculation components, which distinguishes it from narrower sibling tools, but it never explicitly names an alternative such as calculate_custo_demissao or calculate_aviso_previo.

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 states the concrete scenarios in which the tool applies: no-cause termination, resignation, and mutual agreement. It also gives useful contextual conditions like notice_worked and historical reference_date, but it does not state when not to use it or point to a more appropriate sibling.

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