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

Annotations already establish it as a read-only, idempotent, closed-world calculation, and the description adds substantive behavioral context on top: gross amounts before ISR, exclusion of salarios caídos, the assumption of an indefinite-term contract with minimum benefits, and which components are returned. Those caveats materially affect interpretation of the result and are not encoded in any structured field.

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?

Content is front-loaded (what it computes, then the breakdown, then assumptions, then outputs) and every sentence carries weight. The breakdown and the assumptions run together in a single dense block, which slightly hurts scanability for nine parameters.

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 nine-parameter calculator with no output schema, the description covers the legal basis, computational assumptions, exclusions and the shape of the returned values (each concept, finiquito total, indemnización total, grand total). Nothing needed to call it correctly is missing.

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 coverage is 100%, so parameter meaning is already documented, yet the description adds genuine semantics beyond it: the 15-day annual aguinaldo, 25% vacation premium, 12 days per year of seniority premium with a 2-minimum-wage cap, and the rule that the 20-days-per-year indemnity is not automatic. This explains the legal logic driving the boolean toggles rather than restating them.

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?

States a specific verb (calcula) and a precise resource (lo que corresponde al trabajador al terminar la relación laboral bajo la LFT), then enumerates the exact concepts computed (aguinaldo, vacaciones, prima vacacional, prima de antigüedad, indemnización). It is unmistakable against siblings like calcular_sueldo_neto, calcular_iva or calcular_pension_ley73, which cover different domains.

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?

Gives clear applicability conditions: assumes an indefinite-term contract with minimum statutory benefits, excludes salarios caídos and ISR, and specifies which concepts only arise on unjustified dismissal. Boundary conditions are implicit (determinate contracts, union contracts or superior benefits fall outside), but no explicit alternative tool or when-not statement is named.

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