Skip to main content
Glama
Sign In

Delegum

by com.delegum
OverviewDiscussionsAdmin

calcular_irpf

Read-only

Calcula la cuota de IRPF (renta) a partir de los rendimientos del trabajo, capital y ganancias patrimoniales, aplicando gastos deducibles, mínimos personales y familiares. Devuelve cuota íntegra, cuota diferencial (a pagar o devolver) y tipo efectivo. Con bruto_trabajo y es_nomina aplica además la deducción por obtención de rendimientos del trabajo (DA 61.ª LIRPF), que deja sin cuota a quien cobra el SMI.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "rendimientos_trabajo": "<rendimientos_trabajo>"
    },
    "name": "calcular_irpf"
  }
}

Input Schema

NameRequiredDescriptionDefault
es_nominaNotrue si los rendimientos del trabajo son de una nómina (prestación efectiva de servicios); false si son una pensión, que no da derecho a la deducción de la DA 61.ª
num_hijosNoNúmero de hijos. Por defecto 0.
retencionesNoRetenciones ya practicadas en euros
bruto_trabajoNoRendimientos ÍNTEGROS del trabajo (el bruto, antes de la Seguridad Social). Con es_nomina, permite aplicar la deducción de la DA 61.ª LIRPF
situacion_familiarNoSituación familiar. Por defecto "soltero".
rendimientos_trabajoYesRendimientos del trabajo en euros, ya restadas las cotizaciones a la Seguridad Social del trabajador (bruto − SS)
ganancias_largo_plazoNoGanancias patrimoniales >12 meses (base del ahorro)
rendimientos_capital_mobiliarioNoDividendos, intereses... (base del ahorro)
rendimientos_capital_inmobiliarioNoRentas de alquiler... (base general)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / bruto_trabajo
      Added value: +{
+  "description": "Rendimientos ÍNTEGROS del trabajo (el bruto, antes de la Seguridad Social). Con es_nomina, permite aplicar la deducción de la DA 61.ª LIRPF",
+  "minimum": 0,
+  "type": "number"
+}
    • addedInput schema / properties / es_nomina
      Added value: +{
+  "description": "true si los rendimientos del trabajo son de una nómina (prestación efectiva de servicios); false si son una pensión, que no da derecho a la deducción de la DA 61.ª",
+  "type": "boolean"
+}
    • changedInput schema / properties / rendimientos_trabajo / description
      Previous value: -"Rendimientos brutos del trabajo en euros"New value: +"Rendimientos del trabajo en euros, ya restadas las cotizaciones a la Seguridad Social del trabajador (bruto − SS)"
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations only give readOnlyHint=true, so the description must carry the behavioral load: with no output schema it explicitly enumerates what is returned (cuota íntegra, cuota diferencial a pagar o devolver, tipo efectivo), and it discloses a non-obvious conditional behaviour tying bruto_trabajo and es_nomina to the DA 61.ª deduction and the SMI exemption. It does not discuss regional deductions, applicable tax year or input validation limits, which keeps it off a 5.

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?

Three tightly packed sentences: purpose first, return values second, special-case rule last. Every sentence carries information, though the third is a long clause whose parenthetical citation (DA 61.ª LIRPF) could be compressed.

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 calculation tool with 9 optional parameters, no output schema and only a readOnly annotation, the description covers what is computed, the key return fields and the one conditional that changes the result. Remaining gaps — tax year, regional scale applicability, behaviour when optional inputs are omitted — are not addressed but are secondary for correct invocation.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3; the description earns above baseline by explaining the cross-parameter interaction (bruto_trabajo together with es_nomina activates the labour-income deduction) and by framing rendimientos del trabajo as net of Social Security contributions, which the schema states but the description reinforces in context. It adds combination semantics the schema cannot express on its own.

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

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Calcula la cuota de IRPF") and enumerates the income sources it consumes and the deductible/minimum adjustments it applies. The scope is clear enough to separate it from narrow siblings like calcular_plusvalias_irpf or calcular_sueldo_neto, though it never names a sibling explicitly.

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

Usage Guidelines3/5

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

Usage is implied by the input enumeration (labour, capital and patrimonial income), but the description never says when to pick this tool over calcular_plusvalias_irpf, calcular_modelo_130 or calcular_sueldo_neto. There is one clear conditional (bruto_trabajo + es_nomina triggers the DA 61.ª deduction), which is a usage rule, but no alternatives or exclusions are offered.

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

All Delegum toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources