Calculate.co.nz NZ Calculators

nz_road_user_charges_calculator

Work out New Zealand road user charges for an EV, diesel or plug-in hybrid.

Use for: 'how much RUC will I pay', 'what does RUC cost for an EV', 'is a
diesel cheaper than petrol once you count RUC', 'do hybrids pay RUC',
'how much are road user charges a year'.

GET THE VEHICLE TYPE RIGHT, because it changes the rate:
  ev            $76 per 1,000 km
  diesel        $76
  phev_petrol   $38, roughly half, because petrol excise is already paid
  phev_diesel   $76, the FULL rate, since diesel carries no excise
  hybrid_petrol no RUC at all

An ordinary petrol hybrid paying nothing is not an exemption: it pays
through fuel excise at the pump. Say that rather than implying it escapes.

MENTION THE TRANSACTION FEES. RUC is bought in prepaid blocks and every
purchase carries a fee, so 20,000 km in 1,000 km blocks pays it twenty
times. Buying bigger blocks is the main saving available, and it is
invisible if you only multiply distance by rate.

petrol_equivalent_excise answers the question underneath most of these:
whether the RUC vehicle is really paying more than a petrol one.

Light vehicles 3,500 kg and under. Heavy vehicle rates differ and are not
covered.

Args:
    annual_km: Distance driven in a year.
    vehicle_type: ev, diesel, phev_petrol, phev_diesel or hybrid_petrol.
    block_size_km: Size of each RUC purchase.
    purchase_method: online or agent.
    fuel_efficiency_l_per_100km: For the petrol comparison only.

Returns:
    The rate, the charge, the transaction count and fees, the total, cents
    per kilometre, and the equivalent petrol excise.

Input Schema

TableJSON Schema

Name	Required	Default
`annual_km`	Yes
`vehicle_type`	No	diesel
`block_size_km`	No
`purchase_method`	No	online
`fuel_efficiency_l_per_100km`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 1, 2026

TDQS

A4.6/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 burden and does so thoroughly: it discloses fee dependency on block size and purchase method, vehicle-type rate differences, the petrol-hybrid excise distinction, and the heavy-vehicle limitation. It also states what the return includes, which is essential because there is no output schema.

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 long but well-structured: purpose, use cases, rate table, fee warning, scope, args, and returns. It is front-loaded and most blocks earn their place. The sentence beginning 'Work out' appears truncated and the all-caps instructional phrases add some noise, so it is not maximally concise.

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?

Given 5 params, 0% schema coverage, no annotations, and no output schema, this is complete: it covers rates, fees, vehicle-type semantics, exceptions, excluded heavy vehicles, and the return contract. An agent has enough to call it correctly and frame the answer properly.

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 description coverage is 0%, but the Args section compensates by explaining each parameter beyond its name: annual_km is Distance driven in a year, vehicle_type lists all values, purchase_method is online or agent, and fuel_efficiency is explicitly 'For the petrol comparison only.' It could add constraints such as positive distances or fee amounts, but the core meaning is present.

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?

Opens with a specific verb and resource: 'Work out New Zealand road user charges for an EV, diesel or plug-in hybrid.' It enumerates exact vehicle types and rates, so an agent can distinguish it from sibling calculators like nz_fuel_cost_calculator and from generic calculators.

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?

Provides a 'Use for:' list with common user phrasings such as 'how much RUC will I pay' and 'do hybrids pay RUC', and explicitly excludes heavy vehicles. It doesn't name sibling alternates such as nz_fuel_cost_calculator for when-not-to-use, but the use cases and scope make the routning decision clear.

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

All Calculate.co.nz NZ Calculators tools Inspect

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

Need Help?