Calculadoras de México: sueldo neto e ISR, IVA, inflación (INPC), pensión IMSS Ley 73 y liquidación
Scored across 5 tools
Each tool targets a clearly different calculation: inflation adjustment, IVA, labor settlement, Ley 73 pension, and net payroll. Descriptions explicitly fence off neighbors (e.g., inflation vs. CFF 17-A factor, Ley 73 vs. Ley 97), so misselection is unlikely.
Four tools follow a clean calcular_<concepto> snake_case pattern in Spanish, with calcular_pension_ley73 adding a disambiguating suffix. Only actualizar_por_inflacion breaks the verb pattern, a minor but visible deviation.
Five focused calculators is well within the sensible range and each covers a distinct, non-trivial domain calculation. Nothing looks like filler or a redundant variant.
Core payroll/labor/tax calculations are covered, but the descriptions repeatedly point at adjacent operations that are absent (Ley 97/AFORE pension, CFF 17-A fiscal factor, standalone aguinaldo/vacaciones, IVA retentions, RESICO/honorarios). For a general 'calculadoras de México' surface these are notable gaps an agent will hit.
Actualiza un importe en pesos mexicanos entre dos meses con el Índice Nacional de Precios al Consumidor (INPC) general del INEGI, serie mensual oficial desde enero de 1990 hasta el último mes publicado. Devuelve los dos valores del INPC usados, el factor (INPC final ÷ INPC inicial), la inflación acumulada y anualizada en %, la pérdida de poder adquisitivo y el monto actualizado. Sin «monto» devuelve sólo los índices; con la misma fecha en inicio y fin devuelve el INPC de ese mes. Ambos meses deben existir en la serie (formato AAAA-MM); si no, responde con el rango disponible. Es la actualización económica: NO es el factor de actualización fiscal del art. 17-A del CFF (que usa el mes anterior y cuatro decimales).
| Name | Required | Description | Default |
|---|---|---|---|
| monto | No | Opcional. Importe en pesos de «fecha_inicio». Si se omite, sólo se devuelven los INPC y la inflación. | |
| fecha_fin | Yes | Mes de destino, formato AAAA-MM (hasta el último INPC publicado). | |
| fecha_inicio | Yes | Mes de origen, formato AAAA-MM (desde 1990-01). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description goes well beyond them: it enumerates the returned fields (both INPC values, factor, accumulated and annualized inflation, purchasing-power loss, updated amount), and describes conditional output behavior for omitted monto, identical dates, and invalid months. This is unusually rich behavioral disclosure.
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?
Front-loaded with purpose and output, then edge cases, then the sibling/inverse distinction last. It is dense rather than padded, though the single long paragraph could be slightly tighter; every clause carries distinct 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?
With no output schema, the description fully carries the burden of explaining return values, and it also covers the domain boundary (economic vs fiscal adjustment), input format constraints, and failure behavior. Nothing an agent needs 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% and the schema already documents all three parameters, so the baseline is 3. The description adds value by explaining the downstream consequence of omitting monto and of passing identical start/end dates, which the schema does not state for the date pair.
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+resource (update MXN amounts between two months via INPC) with the exact data source and coverage window (INEGI monthly series, 1990-01 onward). It also explicitly distinguishes itself from the confusable fiscal update factor of art. 17-A CFF, so an agent can route correctly 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?
Gives explicit when-to-use conditions (two months in the series, optional monto) and an explicit when-NOT-to-use exclusion (this is not the fiscal update factor from CFF art. 17-A). It also routes edge cases: no monto, identical start/end dates, and out-of-range months.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calcula el Impuesto al Valor Agregado (IVA) de México sobre un importe. «agregar» suma el IVA a un precio que no lo trae (precio × 1.16); «quitar» obtiene el importe sin IVA de un precio que ya lo incluye (precio ÷ 1.16); «desglosar» separa un total con IVA en base e IVA. Tasa general 16 % o 8 % del estímulo de la región fronteriza norte o sur. No calcula retenciones de IVA ni la tasa 0 % o exenta. Devuelve importe sin IVA, IVA e importe con IVA, redondeados a centavos.
| Name | Required | Description | Default |
|---|---|---|---|
| tasa | No | 0.16 = tasa general; 0.08 = estímulo de la región fronteriza norte o sur. | |
| monto | Yes | Importe en pesos mexicanos. | |
| operacion | Yes | «agregar»: el monto NO trae IVA y se le suma. «quitar»: el monto YA trae IVA y se quiere el importe sin IVA. «desglosar»: el monto YA trae IVA y se quiere separar base e IVA. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so safety is covered; the description adds real behavioral context: the exact formulas applied per operation, the rounding to centavos, and the return shape (importe sin IVA, IVA, importe con IVA). It does not mention validation limits such as the maximum monto, but that gap is minor.
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?
Front-loaded with the core action, then operation semantics, then exclusions and return values; no filler. It is dense but each sentence carries operational information; the rate sentence overlaps slightly with the tasa parameter description but is acceptable.
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 compensates by specifying the three returned fields and their rounding. Exclusions and supported rates are also stated, leaving nothing essential unknown for a 3-parameter calculation tool.
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 the baseline is 3; the description goes beyond by explaining what each operation value does arithmetically and by noting which rates exist (16 % general, 8 % frontera) plus which cases are out of scope. It adds meaning rather than repeating 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 specific verb and resource (calcular el IVA de México sobre un importe) and immediately enumerates the three operations it supports with their formulas. The sibling tools are all distinct calculators (inflación, liquidación, pensión, sueldo neto), so the resource alone clearly separates it.
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 defines when each operation applies («agregar»: el monto NO trae IVA; «quitar»/«desglosar»: el monto YA trae IVA) and states exclusions: no retenciones, no tasa 0 % ni exenta. This is exactly the when/when-not guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calcula lo que corresponde a un trabajador en México al terminar la relación laboral, según la Ley Federal del Trabajo. Desglosa: aguinaldo proporcional (15 días al año), vacaciones del periodo en curso más las pendientes, prima vacacional (25 %), prima de antigüedad (12 días por año con tope de 2 salarios mínimos; procede en cualquier despido o en renuncia con 15+ años), y, sólo en despido injustificado, la indemnización constitucional de 3 meses de salario integrado y, si se pide, los 20 días por año. Supone contrato por tiempo indeterminado y prestaciones mínimas de ley; importes brutos antes de ISR; no incluye salarios caídos. Devuelve cada concepto, el total del finiquito, el de la indemnización y el total.
| Name | Required | Description | Default |
|---|---|---|---|
| tipo_salida | Yes | Motivo de la salida. Sólo el despido injustificado genera indemnización. | |
| fecha_salida | Yes | Fecha de terminación de la relación laboral, AAAA-MM-DD. | |
| fecha_ingreso | Yes | Fecha de ingreso, AAAA-MM-DD. | |
| salario_diario | Yes | Salario diario ordinario en pesos (sueldo mensual ÷ 30). | |
| zona_frontera_norte | No | true si aplica el salario mínimo de la frontera (cambia el tope de la prima de antigüedad). | |
| incluir_20_dias_por_anio | No | Sólo en despido injustificado: sumar los 20 días por año (Art. 50 fr. II). No proceden en automático; el importe se informa aunque quede en false. | |
| incluir_prima_antiguedad | No | Sumar la prima de antigüedad cuando proceda (despido de cualquier tipo, o renuncia con 15+ años). | |
| dias_vacaciones_pendientes | No | Días de vacaciones NO disfrutados de periodos ANTERIORES; las del periodo en curso se calculan solas. | |
| incluir_aguinaldo_proporcional | No | Sumar el aguinaldo proporcional del año (false si ya se pagó). |
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.
Estima la pensión mensual de cesantía en edad avanzada (60–64 años) o vejez (65) del IMSS bajo la Ley del Seguro Social de 1973, para quien empezó a cotizar antes del 1 de julio de 1997. Aplica la tabla del Art. 167 (cuantía básica + incrementos por semanas arriba de 500), el factor por edad del Art. 171 (6 meses o más cuentan como año), el factor transitorio 1.11 o, si la pensión resulta menor, la pensión mínima garantizada, y las asignaciones familiares (+15 % cónyuge, +10 % por hijo). Exige al menos 500 semanas y una edad de 60 a 65. Devuelve la pensión mensual, el aguinaldo anual, cada paso de la tabla usado y si se aplicó el piso mínimo. No calcula pensiones de Ley 97 (AFORE) ni Modalidad 40.
| Name | Required | Description | Default |
|---|---|---|---|
| hijos | No | Hijos con derecho (menores de 16, o hasta 25 si estudian): +10 % cada uno. | |
| conyuge | No | true si hay esposa(o) o concubina(o) con derecho: +15 %. | |
| edad_retiro | Yes | Años cumplidos al retirarse: 60–64 = cesantía (75 % a 95 %), 65 = vejez (100 %). | |
| ascendientes | No | Padres que dependen económicamente: +10 % c/u, sólo si no hay cónyuge ni hijos. | |
| ayuda_asistencial | No | +15 % si no hay cónyuge, hijos ni ascendientes. | |
| meses_adicionales | No | Meses cumplidos además de los años. 6 o más cuentan como año completo (Art. 171). | |
| semanas_cotizadas | Yes | Semanas cotizadas reconocidas por el IMSS. Mínimo legal para pensionarse: 500. | |
| salario_promedio_mensual | No | Alternativa al anterior: el mismo promedio expresado en pesos MENSUALES. Envía sólo uno de los dos. | |
| salario_promedio_diario_ultimas_250_semanas | No | Salario base de cotización DIARIO promedio de las últimas 250 semanas (el que aparece en el reporte del IMSS). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Las anotaciones ya cubren que es una operación de solo lectura, idempotente y no destructiva. La descripción añade contexto conductual relevante más allá de las anotaciones: explica la tabla del Art. 167, el factor de edad del Art. 171, el factor transitorio 1.11, el piso mínimo garantizado y las asignaciones familiares.
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?
La información está front-loaded al comenzar con qué estima y para quién aplica. Es densa y contiene una oración larga con muchos detalles legales, pero prácticamente cada elemento aporta contexto relevante para el cálculo.
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?
No hay esquema de salida, pero la descripción compensa indicando que devuelve pensión mensual, aguinaldo anual, pasos de la tabla y si se aplicó el piso mínimo. Para una calculadora compleja de 9 parámetros, la descripción cubre elegibilidad, fórmula, exclusiones y resultados esperados de forma suficiente.
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?
La cobertura del esquema es del 100%, por lo que la línea base sería 3. La descripción añade semántica útil sobre varios parámetros clave, como las semanas arriba de 500, el redondeo de meses por edad y los porcentajes por cónyuge e hijos, aunque no detalla todos los parámetros de la misma forma.
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?
Estima una pensión mensual del IMSS bajo la Ley 73, especificando cesantía en edad avanzada o vejez y el requisito de cotización antes de julio de 1997. Distingue claramente el alcance frente a Ley 97 (AFORE) y Modalidad 40, por lo que un agente puede identificarlo sin ambigüedad.
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?
Indica condiciones de uso claras: edad de 60 a 65, al menos 500 semanas y haber empezado a cotizar antes del 1 de julio de 1997. También declara exclusiones explícitas ('No calcula pensiones de Ley 97 ni Modalidad 40'), aunque no nombra una herramienta alternativa concreta para esos casos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calcula la nómina de un trabajador asalariado en México (ejercicio 2026) a partir de su sueldo bruto MENSUAL: ISR retenido con la tarifa oficial del Art. 96 LISR y el subsidio al empleo, cuotas del IMSS del trabajador por rama sobre el salario base de cotización, sueldo neto y costo total para el patrón (cuotas IMSS patronales + 5 % Infonavit). Supone prestaciones mínimas de ley (15 días de aguinaldo, 12 de vacaciones, 25 % de prima vacacional), prima de riesgo clase I y nada de percepciones extra ni deducciones adicionales; no incluye el impuesto estatal sobre nómina. Devuelve cifras mensuales y por periodo (mensual, quincenal o semanal) con desglose por concepto. No sirve para honorarios, RESICO ni aguinaldo: sólo sueldos y salarios.
| Name | Required | Description | Default |
|---|---|---|---|
| mes | No | Opcional. Mes de la nómina (1–12); por defecto el mes en curso. Enero usa la UMA del año anterior. | |
| anio | No | Ejercicio fiscal. Por ahora sólo 2026. | |
| periodicidad | No | Cada cuánto se paga. El ISR del periodo se calcula con la tarifa de ese periodo. | mensual |
| zona_frontera_norte | No | true si el trabajo está en la Zona Libre de la Frontera Norte (salario mínimo de frontera). | |
| sueldo_bruto_mensual | Yes | Sueldo bruto MENSUAL en pesos mexicanos (antes de impuestos), aunque se cobre por quincena o por semana. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare read-only/idempotent/closed-world; the description goes well beyond by disclosing every modeling assumption baked into the numbers (15 días aguinaldo, 12 de vacaciones, 25% prima vacacional, prima de riesgo clase I, exclusión del impuesto estatal sobre nómina) and what the response contains. That is exactly the context an agent needs to decide whether the output is trustworthy for a given question.
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?
Front-loaded with the verb, scope and input basis, then assumptions, then the exclusions — a logical order with no filler. It is a single dense paragraph, though, and the assumption list could be scannable bullets rather than one long clause chain.
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?
No output schema exists, yet the description still tells the agent what comes back ('cifras mensuales y por periodo ... con desglose por concepto'), and the legal/assumption caveats plus the exclusion list cover the remaining ambiguity for a calculation tool with one required parameter.
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 schema already carries mes, anio, periodicidad, zona_frontera_norte and the monthly-gross constraint. The description reinforces that the input is MENSUAL regardless of pay period and that periodicidad drives the ISR tarifa, but adds no syntax or edge-case detail beyond the structured fields, so the 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 specific verb and resource (calcula la nómina de un trabajador asalariado en México) and enumerates exactly which components it computes: ISR Art. 96, subsidio al empleo, cuotas IMSS del trabajador y patronales, neto y costo patronal. It explicitly fences itself off from calcular_liquidacion / calcular_pension / honorarios / RESICO, so an agent can separate it from every sibling without opening a 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?
Gives a clear when-not boundary ('No sirve para honorarios, RESICO ni aguinaldo: sólo sueldos y salarios') plus the stipulations that make the result valid (prestaciones mínimas de ley, prima de riesgo clase I, sin percepciones extra, sin impuesto estatal). It does not name the sibling tool an agent should use instead for liquidaciones or pensiones, leaving that routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
calcular_pension_ley735 fields changedInput schema / properties / ascendientes / descriptionPrevious value: -"Padres que dependen económicamente: +10% c/u, sólo si no hay cónyuge ni hijos."New value: +"Padres que dependen económicamente: +10 % c/u, sólo si no hay cónyuge ni hijos."Input schema / properties / ayuda_asistencial / descriptionPrevious value: -"+15% si no hay cónyuge, hijos ni ascendientes."New value: +"+15 % si no hay cónyuge, hijos ni ascendientes."Input schema / properties / conyuge / descriptionPrevious value: -"true si hay esposa(o) o concubina(o) con derecho: +15%."New value: +"true si hay esposa(o) o concubina(o) con derecho: +15 %."Input schema / properties / edad_retiro / descriptionPrevious value: -"Años cumplidos al retirarse: 60–64 = cesantía (75% a 95%), 65 = vejez (100%)."New value: +"Años cumplidos al retirarse: 60–64 = cesantía (75 % a 95 %), 65 = vejez (100 %)."Input schema / properties / hijos / descriptionPrevious value: -"Hijos con derecho (menores de 16, o hasta 25 si estudian): +10% cada uno."New value: +"Hijos con derecho (menores de 16, o hasta 25 si estudian): +10 % cada uno."actualizar_por_inflacioncalcular_ivacalcular_liquidacioncalcular_pension_ley73calcular_sueldo_netoFiscal y nomina MX: recargos, ISR, CFDI, RESICO, calendario, IMSS, aguinaldo, finiquito.
Fiscalidad, derecho laboral y finanzas de España: IRPF, autónomos (cuota RETA, modelos 130 y 303, gastos deducibles), nóminas de bruto a neto, despidos (indemnización, finiquito, paro), herencias y donaciones por comunidad autónoma, jubilación y pensiones, hipotecas y compraventa de vivienda. Incluye consultas de escenario que combinan varios cálculos a la vez, como haría una gestoría. Gratuito, sin registro ni API key.
Calculatrices francaises : salaire net, SMIC, impots, bareme kilometrique, TVA, conversions.
Paraguay & Ecuador tax and labor calculators: IVA, severance, payroll, income tax, fines, RUC/CDC.
Add one secure layer between your agents and this server.
