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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false and openWorldHint=false, yet the description still adds real value: determinism (same input, same output), no network or persisted state, and concrete limits (64 KB input, 1 s per call, 1 MB output). It also flags that the output contains "normas y puntos no verificados" and that the count uses 360-day periods, which is behaviorally important and not derivable from annotations.

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?

Labeled sections (Cuándo / No para / Efectos secundarios / Determinista / Límites) are well front-loaded, but the text is duplicated bilingually across the description and again inside inputSchema.description, roughly doubling length without new information. The clause "normas y puntos no verificados" is vague and does not earn its space as written.

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?

An output schema exists and annotations cover safety, so the description need not explain return values; what it must carry — determinism, limits, exclusion of the retención sibling, and the 360-day convention — is present. The remaining gap is that the "when to use" trigger is generic boilerplate rather than specific to severance computation.

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 all five parameters are already documented, including the transport-allowance default of $249.095 and the "0 = not paid" convention. The description adds only the underlying conventions (12% interest, 360-day basis, fixed non-integral salary) rather than parameter-level detail, so baseline 3 is appropriate.

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 and resource ("Calcula la liquidación de prestaciones sociales en Colombia") and enumerates the exact components computed: cesantías, 12% interest, prima de servicios, vacaciones pendientes, transport allowance, 360-day counting. Scope is bounded to a fixed salary between two dates, so an agent can tell it apart from generic salary or retención tools without opening the schema.

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 "No para" clause is a genuine strength: it explicitly excludes monthly income-tax withholding and names the sibling co-retencion-salarios. However, the "Cuándo" clause is boilerplate that does not match this tool — it cites DIAN, Ley Emiliani holidays, IVA, GMF and UVT and mentions "facturar o cobrar", none of which relate to severance calculation, so an agent could be routed here for VAT or GMF work. The correct trigger (applying a Colombian severance rule) is only implicit.

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