Skip to main content
Glama

Calculate.co.nz NZ Calculators

nz_parental_leave_calculator

New Zealand paid parental leave: the payment, and the shortfall.

Use for: 'how much is paid parental leave', 'can I afford to take parental
leave', 'am I eligible for parental leave', 'how much less will I earn on
parental leave'.

LEAD YOUR ANSWER WITH THE GAP, not the payment. The payment is capped, so
anyone earning over roughly $42,000 receives exactly the cap and already
knows that number. What they do not know is weekly_gap and total_gap, how
much less arrives and what it adds up to over the leave. That is the figure
the decision actually turns on.

Eligibility is a gate, not a reduction: 26 weeks of work in the year before
the due date, at 10 or more hours a week. Fail either and the payment is
zero. ineligible_reason names which test failed and by how much, so say
that rather than only "not eligible".

Args:
    annual_income: Gross annual income before tax, in NZD.
    employment_type: "employee" or "self_employed". Only the self-employed
        get the statutory weekly minimum.
    hours_per_week: Average hours a week.
    weeks_worked: Weeks worked in the 52 before the due date.
    weeks_of_leave: Weeks of the 26 week entitlement this parent takes.
    kiwisaver_opt_in: Contributions during leave are OPT IN. Worth raising
        unprompted: someone who does nothing contributes nothing for the
        whole period, employer share included.
    kiwisaver_rate: Employee rate as a decimal.

Returns:
    Weekly and total payment, the weekly and total gap against usual pay,
    eligibility with a reason, weeks left for a partner, and what opting
    into KiwiSaver is worth over the leave.

IRD administers this and its assessment is the one that counts. Does not
cover preterm baby payments, keeping in touch hours, or partner transfers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
weeks_workedNo
annual_incomeYes
hours_per_weekNo
kiwisaver_rateNo
weeks_of_leaveNo
employment_typeNoemployee
kiwisaver_opt_inNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries the full transparency burden and succeeds. It discloses the payment cap, the strategic emphasis on the gap rather than the payment, the eligibility gate with zero payment on failure, the ineligible_reason field, and the KiwiSaver opt-in nuance. It also notes IRD's authority, giving an agent important context about the tool's limits.

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

Conciseness5/5

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

The description is long but well-structured and every section earns its place: purpose, decision-critical guidance, eligibility, args, returns, and exclusions. It is front-loaded with the key instruction to lead with the gap, and formatting makes it easy to scan. No fluff or repetition exists.

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 7-parameter calculator with no output schema and no annotations, the description is remarkably complete. It covers all inputs, output components, eligibility rules, edge cases, and exclusions. An agent can select the tool, populate parameters correctly, and interpret results including ineligibility and KiwiSaver implications.

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%, but the Args section comprehensively documents all seven parameters with units, formats, and special rules. For example, annual_income is defined as gross pre-tax NZD, employment_type has explicit values, and kiwisaver_rate is identified as a decimal. This fully compensates for the empty schema descriptions.

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 precisely identifies the resource and function: New Zealand paid parental leave, including both the payment and the shortfall. It lists concrete user queries, making it immediately clear what the tool does. Its domain is distinct from all sibling calculators, such as annual leave, PAYE, or redundancy, so there is no ambiguity about which tool to invoke.

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?

The description provides explicit 'Use for' scenarios, covering common questions like 'how much is paid parental leave' and 'can I afford to take parental leave'. It also states clear exclusions (preterm baby payments, keeping in touch hours, partner transfers) and advises how to handle ineligibility. This gives strong when-to-use and when-not-to-use guidance, even without naming a specific alternative sibling.

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