Skip to main content
Glama

calcular_complemento_brecha_genero

Read-only

Calcula el complemento de pensión para la reducción de la brecha de género (antiguo complemento de maternidad, art. 60 LGSS). Importe fijo por hijo/a (la cuantía vigente y el máximo de hijos salen de data/fiscal; se abona en 14 pagas) sobre pensiones contributivas de jubilación, incapacidad permanente o viudedad. IMPORTANTE: tras la STJUE C-623/23 (15 de mayo de 2025) y la STS de 9 de julio de 2025, hombres y mujeres tienen derecho en IGUALDAD de condiciones — ya NO se exigen requisitos adicionales a los hombres. Requisitos: pensión contributiva, hecho causante desde el 4 de febrero de 2021 y al menos 1 hijo. Que el otro progenitor ya lo perciba por los mismos hijos NO lo deniega: cada hijo da derecho a un solo complemento y el art. 60.1 LGSS lo asigna al progenitor titular de pensiones públicas cuya SUMA sea de menor cuantía; reconocérselo al segundo extingue el del primero (art. 60.2). En ese caso indica suma_pensiones_menor; sin ella el veredicto es condicionado.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sexoYesSexo del beneficiario (informativo: desde la doctrina 2025 no afecta al derecho)
num_hijosYesNúmero de hijos/as nacidos con vida o adoptados antes del hecho causante
tipo_pensionYesTipo de pensión. Solo las contributivas dan acceso, y la jubilación parcial queda excluida por el art. 60.4 LGSS.
otro_progenitorNoSituación del OTRO progenitor (no del solicitante): no_percibe, percibe (ya lo cobra por esos hijos: no es incompatible, decide suma_pensiones_menor), denegado, no_aplica. Que se lo denegaran a ÉL no da derecho a reclamar: para eso está denegacion_propia. Por defecto no_percibe.
denegacion_propiaNo¿Al SOLICITANTE le denegaron el complemento en su día y tiene una resolución denegatoria? Es lo que decide si procede reclamar (STJUE C-623/23, para denegaciones a hombres anteriores a esa doctrina). Por defecto false.
fecha_hecho_causanteNoMomento del hecho causante. El complemento exige hecho causante desde el 4 de febrero de 2021. Por defecto desde_2021.
suma_pensiones_menorNoSolo si otro_progenitor es "percibe": de quién es la SUMA de pensiones públicas (todas, p. ej. jubilación + viudedad) de menor cuantía. propia → se le reconoce al solicitante y se extingue el del otro; otro_progenitor → lo conserva el otro; desconocida (por defecto) → veredicto condicionado.
cuantia_pension_mensualNoCuantía mensual de la pensión base (€/mes). Opcional: para mostrar la pensión total con complemento.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / denegacion_propia / description
      Previous value: -"¿Al SOLICITANTE le denegaron el complemento en su día y tiene una resolución denegatoria? Es lo que decide si procede reclamar (STJUE C-623/23 para denegaciones a hombres anteriores a 2025). Por defecto false."New value: +"¿Al SOLICITANTE le denegaron el complemento en su día y tiene una resolución denegatoria? Es lo que decide si procede reclamar (STJUE C-623/23, para denegaciones a hombres anteriores a esa doctrina). Por defecto false."
    • changedInput schema / properties / otro_progenitor / description
      Previous value: -"Situación del OTRO progenitor (no del solicitante): no_percibe, percibe (incompatible, el complemento ya se reconoció por esos hijos), denegado, no_aplica. Que se lo denegaran a ÉL no da derecho a reclamar: para eso está denegacion_propia. Por defecto no_percibe."New value: +"Situación del OTRO progenitor (no del solicitante): no_percibe, percibe (ya lo cobra por esos hijos: no es incompatible, decide suma_pensiones_menor), denegado, no_aplica. Que se lo denegaran a ÉL no da derecho a reclamar: para eso está denegacion_propia. Por defecto no_percibe."
    • addedInput schema / properties / suma_pensiones_menor
      Added value: +{
      +  "description": "Solo si otro_progenitor es \"percibe\": de quién es la SUMA de pensiones públicas (todas, p. ej. jubilación + viudedad) de menor cuantía. propia → se le reconoce al solicitante y se extingue el del otro; otro_progenitor → lo conserva el otro; desconocida (por defecto) → veredicto condicionado.",
      +  "enum": [
      +    "propia",
      +    "otro_progenitor",
      +    "desconocida"
      +  ],
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / fecha_hecho_causante / description
      Previous value: -"Momento del hecho causante. El complemento exige hecho causante desde el 04/02/2021. Por defecto desde_2021."New value: +"Momento del hecho causante. El complemento exige hecho causante desde el 4 de febrero de 2021. Por defecto desde_2021."
  3. Changed2 schema fields changed
    • changedInput schema / properties / tipo_pension / description
      Previous value: -"Tipo de pensión. Solo las contributivas dan acceso."New value: +"Tipo de pensión. Solo las contributivas dan acceso, y la jubilación parcial queda excluida por el art. 60.4 LGSS."
    • changedInput schema / properties / tipo_pension / enum
      Previous value: -[
      -  "jubilacion",
      -  "incapacidad_permanente",
      -  "viudedad",
      -  "no_contributiva",
      -  "ninguna"
      -]New value: +[
      +  "jubilacion",
      +  "jubilacion_parcial",
      +  "incapacidad_permanente",
      +  "viudedad",
      +  "no_contributiva",
      +  "ninguna"
      +]
  4. Changed2 schema fields changed
    • addedInput schema / properties / denegacion_propia
      Added value: +{
      +  "description": "¿Al SOLICITANTE le denegaron el complemento en su día y tiene una resolución denegatoria? Es lo que decide si procede reclamar (STJUE C-623/23 para denegaciones a hombres anteriores a 2025). Por defecto false.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / otro_progenitor / description
      Previous value: -"Situación del otro progenitor: no_percibe, percibe (incompatible), denegado (posible reclamación), no_aplica. Por defecto no_percibe."New value: +"Situación del OTRO progenitor (no del solicitante): no_percibe, percibe (incompatible, el complemento ya se reconoció por esos hijos), denegado, no_aplica. Que se lo denegaran a ÉL no da derecho a reclamar: para eso está denegacion_propia. Por defecto no_percibe."
  5. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses substantial behavioral context: the fixed per-child amount paid in 14 pagas, the 2025 CJEU/Supreme Court doctrine equalizing men and women, the non-exclusive effect of the other parent receiving it, the lower-sum rule of art. 60.1, extinction under art. 60.2, and the conditional verdict when suma_pensiones_menor is unknown. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loaded with the purpose and the key legal update, and every sentence adds decision-relevant information. It is long, but the complexity of the legal rules justifies the length; a bulleted structure could improve scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 8 parameters, 5 enums, and no output schema, the description covers all decision-relevant context: eligibility, exclusions, legal basis, inter-parent conflict, and conditional outcome. However, it never states the shape of the result (e.g., eligibility verdict plus amount), so an agent must infer the return format from 'Calcula' and 'veredicto'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds meaning beyond the schema: it explains that the amount is fixed per child and sourced from data/fiscal, that the other parent's receipt is not a denial and instead triggers the suma_pensiones_menor decision, and that omitting that parameter yields a conditional verdict. This materially clarifies how to set otro_progenitor, suma_pensiones_menor, and fecha_hecho_causante.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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 el complemento de pensión para la reducción de la brecha de género (antiguo complemento de maternidad, art. 60 LGSS)'. It further delimits the tool by listing eligible pension types and the legal article, making it clearly distinct from siblings like calcular_deduccion_maternidad_irpf or calcular_prestacion_maternidad_paternidad.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit conditions for use: contributory pension, hecho causante desde el 4 de febrero de 2021, and at least one child, and it notes that non-contributory pensions are excluded. It does not name sibling tools or state 'use this instead of X', so it stops short of a full when/when-not comparison.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources