Calculadoras laborales y tributarias PY/EC

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

Annotations already declare read-only, idempotent, non-destructive and closed-world, so the bar is lower. The description still adds real value: it fixes the exact statutory rates applied, pins SBU 2026 at USD 482, and notes that the response also carries official sources plus a web-calculator link — a return-content hint that matters since no output schema exists.

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?

Three sentences, front-loaded with the outcome ('costo mensual y del período'), then per-country detail, then return contents. The rate lists are dense but each figure earns its place by telling the agent what is being computed.

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 four-parameter, no-output-schema calculator with solid annotations, this covers purpose, both country regimes and the shape of the response. The remaining gap is disambiguation from sibling calculators and how the period/months field interacts with the aguinaldo and décimo accrual.

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 parameters are already documented. The description restates what the country choice implies (which contributions and bonuses are included per regime), which is a useful restatement but adds little beyond the enum descriptions and the 'reserva' parameter note in the schema.

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 concrete resource and scope: monthly and period payroll cost for the employer, naming the specific statutory components (IPS, aguinaldo, IESS, décimos, fondo de reserva). It is distinguishable from siblings like calcular_liquidacion_laboral or calcular_impuesto_renta by the domain it covers, though it never explicitly says so.

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 says what is computed but never when to call it versus the other eight labour/fiscal calculators, nor any preconditions (e.g. that it is a projection over a period, not a settlement). An agent must infer the routing from the tool name alone.

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

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

The annotations already declare it as read-only, idempotent, non-destructive and closed-world. The description adds useful behavioral context beyond them: it says the tool includes IESS/IPS contributions, décimo tercero/aguinaldo, employer cost, worker net pay, official sources and a web calculator link. It does not state calculation assumptions or approximation caveats, so it is strong but not 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?

The description is compact and front-loads the core calculation and country scope. The long rate enumeration is dense but earns its place because it maps directly to the hour categories the caller must supply.

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?

There is no output schema, but the description explains the main computed outputs: overtime value, cost, contributions, proportional thirteenth/aguinaldo, employer cost, worker net, official sources and calculator link. It still omits calculation assumptions and error behavior, which matters for a legal payroll calculator.

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 baseline would be 3. The description adds value by giving the actual percentage surcharges for each hour bucket (+50%, +100%, 25%, 30%) and linking them to country-specific overtime categories, which helps interpret the nested hours object beyond the schema's category names.

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 states a specific calculation: the value and cost of monthly overtime for Paraguay and Ecuador, including country-specific rate categories. That is clearly distinct from sibling calculators such as income tax, IVA, liquidación laboral or aguinaldo/IPS/décimos.

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 implied by the country-specific overtime calculation and the listed rate categories. However, it does not explicitly say when to use this tool instead of the sibling payroll/tax calculators, nor does it state exclusions or prerequisites.

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

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

Annotations confirm it is safe and read-only. The description adds crucial behavioral detail by specifying the calculation methodology (e.g., Ecuador: SRI 2026 tables; Paraguay: IRP brackets) and the expected output (official sources/links).

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?

The description is highly concise and efficient, managing the complexity of two different national tax systems into one cohesive and front-loaded paragraph.

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 the inherent complexity of modeling two separate, real-world annual income tax systems, the definition is complete. It covers rules, scope, calculation methods, and even expected output (links/sources).

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%, meeting the baseline. However, the description significantly adds value by contextualizing the parameters within the specific tax logic (e.g., defining 'cargas' as family benefits/rebates for Ecuador and outlining deducible expenses for Paraguay).

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 purpose is perfectly clear: calculating the annual income tax for employed workers. It distinguishes itself by explicitly naming the dual scope (Ecuador 2026 SRI tables vs. Paraguay IRP brackets).

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?

It defines a clear use case (annual tax calculation based on specific national rules). While it doesn't list all alternatives, its highly specific domain distinguishes it implicitly from sibling payroll calculation tools.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description still adds real behavioral detail beyond them: currency-specific rounding (cents in Ecuador, whole guaraníes in Paraguay), the ÷11 / ÷21 included-tax formula, per-line and per-rate output aggregation, the legal norm attached to each rate, and that official sources plus a web calculator link are returned.

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 front-loaded sentences with no filler, leading with the operation and then the per-country specifics. The rate enumeration (15/5/0 and 10/5/ex) duplicates the schema's enum text and could be trimmed without losing information.

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?

There is no output schema, and the description compensates by describing the return shape (base, IVA, total per line and per rate, plus the applicable norm and official sources). Nothing an agent needs in order to invoke this 3-parameter, all-required tool 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% with rich enum descriptions, so the baseline is 3; the description earns an extra point because the 'precio ÷ 11 o ÷ 21' rule clarifies what the extract mode actually computes, which the schema does not state. It largely repeats the rate table already documented in the enum descriptions.

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 concrete verb pair ('agrega o saca el IVA') plus the resource (montos/facturas) and the two jurisdictions (Paraguay DNIT, Ecuador SRI). This is unmistakably distinct from the sibling calculators (aguinaldo, horas extras, renta, retenciones, multas), so an agent can route 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 description conveys clear usage context: which countries and which statutory rates apply, and the add-vs-extract semantics are spelled out (reinforced by the schema enum). It does not explicitly state when to pick this tool over a sibling or any exclusion (e.g. non-VAT taxes), leaving that to obvious domain inference.

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

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

The description provides strong behavioral context by specifying that the output includes the relevant articles from the Labor Code for each line item. It also mentions external outputs like official sources and web calculator links, which is critical for a comprehensive assessment.

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?

The single paragraph is highly efficient. It front-loads the core function, defines the scope, and details the unique features (legal articles/links) without any filler.

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?

Because it does not have an output schema, the description is essential and provides complete information on the returned values, listing specific outputs like articles, sources, and links, making it entirely usable by the agent.

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?

Despite the 100% schema coverage, the description adds vital semantic context (e.g., 'Paraguay: promedio de los últimos 6 meses si varía' for salary) and specifies the legal basis for the calculations ('con el artículo del Código del Trabajo de cada línea'), greatly enriching the parameter understanding.

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 explicitly identifies the purpose as calculating labor liquidation. It scopes the function to two specific jurisdictions (Paraguay and Ecuador), clearly distinguishing it from the component calculation tools in the sibling list.

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 defines the scope of the calculation: termination scenarios, including specific components like indemnification, severance, notice, and various proportions. This provides a clear definition of when and how the tool should be used in a financial planning context.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and closed-world, so the safety profile is covered. The description adds value beyond that by disclosing the return payload ('fuentes oficiales y el link a la calculadora web') and the legal basis of the computation, which since there is no output schema is genuinely useful.

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?

The core purpose is front-loaded in the first clause, and the country-specific detail follows logically. It is dense with legal citations but each clause maps to an actual computation branch, so little is wasted; only the article numbers could be trimmed.

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 9-parameter, no-output-schema calculation tool with full schema coverage, the description supplies what the schema can't: the legal regimes, the fine components, and the shape of the return. The only remaining gap is guidance on the conditional/optional parameters, which the description leaves entirely to the schema.

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 each of the 9 parameters is already documented in the schema, giving the baseline of 3. The description adds calculation context (the 0.1% sales base in Ecuador, the 4%-14% plus 1.5% monthly in Paraguay) but does not clarify parameter interactions such as when noTax, sales, or causado become required.

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 (calculate late-filing fines, default interest, and total payable) with the exact legal regimes covered (Ecuador SRI art. 100 LRTI, Paraguay DNIT art. 171 Ley 125/91). This clearly separates it from siblings like calcular_multas_lavado_activos or calcular_impuesto_renta without needing to open 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?

Usage is only implied through the scenario wording ('por declarar o pagar tarde'), so an agent can infer it applies to overdue filings/payments. However, it never explicitly names when to prefer a sibling tool, nor what preconditions are needed (e.g., that country must be py or ec), leaving routing to inference.

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

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

Annotations already declare a safe, idempotent, closed-world read, so the description's added value is in what it returns: the range in SBU/salarios mínimos and in money, the applicable article, official sources, and a web calculator link. That is meaningful extra context not derivable from the annotations, though it says nothing about precision assumptions or rounding.

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 compact sentences with the legal basis and unit framing front-loaded, then the return contents. Dense but every clause carries information; only the 'Devuelve… Devuelve también…' split is slightly redundant.

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?

With no output schema, the description correctly carries the burden of describing return values (range in units and money, article, official sources, calculator link). It does not state what happens for combinations like a grade supplied with a Paraguay entity, but the schema enums already scope those cases.

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% with detailed per-parameter descriptions, so the baseline is 3. The description adds some legal framing (Ecuador tiers 1-10 / 11-20 / 21-40 SBU by grade; Paraguay caps of 5.000 or 500 salarios mínimos or a % of the operation) that explains how entity/grade/operation interact, but nothing beyond the schema's own text.

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 resource (fines for money-laundering prevention infractions) and scope (Paraguay SEPRELAD Ley 1015/97 and Ecuador UAFE), including the unit basis (SBU / salarios mínimos). It is clearly distinguishable from siblings like calcular_multas_declaracion_tardia by topic, though it never names the sibling explicitly.

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: the agent must infer that this tool is for LA/FT fine ranges rather than other fine or tax calculations. There is no explicit 'use when' statement, no exclusion of the sibling multas tool, and no note on preconditions (e.g., needing to know the entity type first).

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavioral information: it returns official legal sources and a link to the web calculator, which matters because there is no output schema. It says nothing about error handling or how rates are resolved when inputs are ambiguous.

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?

The core question is front-loaded in the first clause, and the rest is dense, example-driven legal context with no filler. It is slightly long with stacked resolution citations, but each sentence carries information an agent cannot get from structured fields.

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 an 11-parameter, two-jurisdiction tool with no output schema, the description covers what is computed, under which rules, and what is returned. The remaining gap is that conditional requirements are only implied (e.g. which parameters become necessary once country=ec vs country=py), leaving the agent to infer the effective schema from per-parameter descriptions.

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 every parameter is already documented with country tags and enum meanings, so the schema does the heavy lifting. The description only supplements with the underlying legal resolutions (NAC-DGERCGC26-00000009, NAC-DGERCGC20-00000061, Decreto 3107/19, Ley 6380/19), which is corroborating context rather than new parameter semantics. Baseline 3 applies.

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 concrete verb and resource ('calcular retenciones') and frames the exact question it answers ('Cuánto retener en una factura y cuánto pagar al proveedor'). It also scopes the two jurisdictions and names the taxes involved, which distinguishes it from siblings like calcular_iva or calcular_impuesto_renta.

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 establishes clear usage context by enumerating the scenarios it covers (Ecuador renta/IVA withholding by buyer type; Paraguay local IVA retention or INR/IDU), which is effectively a when-to-use map. It does not, however, explicitly exclude alternatives or tell the agent when to prefer calcular_iva or calcular_impuesto_renta instead.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false; the description adds genuinely new behavioral context by confirming the check is purely local/offline and that official sources plus a web calculator link are returned. It stops short of describing the response shape in detail or what happens on invalid input.

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 verb and the four document types, with the key limitation placed early in the second sentence. The first sentence is dense with parenthetical qualifiers but every clause carries discriminating information, so there is little waste.

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?

With no output schema, the description carries the return-value burden and does so partially: it says parts are separated and official sources plus a calculator link are returned. For a two-parameter, four-variant validator this is nearly sufficient, though it could say more about the success/failure shape.

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 enum values already map to their meanings, so baseline is 3. The description does add some value by attaching digit lengths (44/49) and the módulo 11 rule to specific types, though it does not restate the whitespace/punctuation tolerance for 'value'.

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 ('Valida la estructura y el dígito verificador') plus every resource it covers: CDC SIFEN 44 dígitos, clave SRI 49 dígitos, RUC Paraguay módulo 11, RUC/cédula Ecuador. The addition of 'y separa sus partes' makes clear it also decomposes the document, and the scope is unmistakable against calculator siblings like calcular_iva or calcular_retenciones.

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?

Explicitly sets the usage boundary: 'Es un cálculo local: no consulta a SIFEN ni al SRI si el documento existe' tells the agent when-not to rely on it (existence verification). It does not name an alternative tool, but no sibling performs validation, so there is nothing to route away from.

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