Skip to main content
Glama

Calculate.co.nz NZ Calculators

nz_lump_sum_tax_calculator

Tax on a New Zealand redundancy or lump sum, by IRD's rate table.

Use for: 'how much tax on my redundancy', 'what will I get from a $40,000
redundancy payment', 'is redundancy taxed differently', 'tax on a
retirement payment', checking a redundancy letter.

TWO RULES MAKE REDUNDANCY DIFFERENT AND BOTH ARE EASY TO MISS. Redundancy
and retirement payments carry NO ACC earner levy, so they always take the
lower rate column whatever the income, and NO KiwiSaver is deducted from
them at all. Treating a redundancy like a bonus overstates the deductions
twice over. Pass payment_type correctly.

This applies IRD's published rate TABLE, where annualised income plus the
lump sum picks one flat rate charged on the whole payment. That is what an
employer deducts on the day. nz_bonus_tax_calculator computes the same tax
the exact way instead, which is roughly where the year-end assessment
lands. Both are right; they give different answers. Use this one to check a
letter or a payslip, and say which method you used.

ALWAYS ask for the annual salary. It selects the rate, so the answer
depends on it entirely.

Args:
    lump_sum: The gross lump sum in NZD.
    annual_salary: Annual salary, used as the annualised income.
    payment_type: redundancy, retirement, bonus, commission, holiday_pay,
        exit_inducement or back_pay.
    kiwisaver_rate: A DECIMAL. Forced to zero for redundancy and retirement.
    has_student_loan: Whether 12% comes off the lump sum.

Returns:
    The rate selected with why_that_rate explaining which row and why, the
    PAYE, other deductions, and the net amount received.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lump_sumYes
payment_typeNoredundancy
annual_salaryYes
kiwisaver_rateNo
has_student_loanNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full disclosure burden and meets it: it reveals the flat-rate-table calculation method, the NO-ACC and NO-KiwiSaver rules for redundancy/retirement, that kiwisaver_rate is forced to zero for those types, and the 12% student-loan deduction. It also sets expectations for the return ('the rate selected with why_that_rate explaining which row and why, the PAYE, other deductions, and the net amount').

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 structure is strong — use-for queries up front, then critical rules, sibling contrast, args, and returns — and the length is justified for a 5-param tool with no annotations and no output schema. It loses a point for the awkward, ambiguous sibling sentence ('computes the same tax the exact way instead') and the somewhat shouty ALL-CAPS emphasis.

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

Completeness5/5

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

For a high-complexity calculator with no annotations, no output schema, and 0% schema description coverage, the description covers purpose, method, edge cases, sibling routing, every parameter's meaning, and the return shape. The only omissions (rounding behavior, invalid payment_type handling) are minor and do not impede a correct invocation.

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?

Schema description coverage is 0%, so the description must carry parameter meaning, and it does for all five: lump_sum is 'the gross lump sum in NZD', payment_type gets its permitted values enumerated (redundancy, retirement, bonus, commission, holiday_pay, exit_inducement, back_pay — the schema has no enum), and kiwisaver_rate is flagged as 'A DECIMAL' with the forced-zero caveat. has_student_loan is tied to the 12% deduction, which the bare schema title does not convey.

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 first sentence names a specific resource and method — 'Tax on a New Zealand redundancy or lump sum, by IRD's rate table' — and the use-for query examples ('how much tax on my redundancy', 'tax on a retirement payment') pin down the intended cases. It further distinguishes itself from nz_bonus_tax_calculator by explaining the two different methods, so an agent can select the right sibling without opening either schema.

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

Usage Guidelines5/5

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

Usage context is explicit: the use-for query patterns tell the agent when this tool applies, and the sibling contrast is unambiguous — 'nz_bonus_tax_calculator computes the same tax the exact way instead, which is roughly where the year-end assessment lands. Both are right; they give different answers. Use this one to check a letter or a payslip.' The 'ALWAYS ask for the annual salary' directive further tells the agent what input to elicit before calling.

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