Calculate.co.nz NZ Calculators

nz_grocery_budget_calculator

Work out a weekly grocery budget for a New Zealand household.

Use for: 'how much should I spend on groceries', 'grocery budget for a
family of four NZ', 'average food bill New Zealand', 'am I spending too
much on food'.

Build the household person by person. A teenager is not a child-sized cost,
and an average per head hides exactly the thing that makes the answer
useful. Member types are child_5_10, teen_11_17, adult_male, adult_female
and elderly_65; list one entry per person.

ALL THREE SPEND LEVELS COME BACK EVERY TIME, and that is the point. A
single figure invites "that seems high". The gap between basic and liberal
for the SAME household, in dollars a year, is the number that changes
behaviour, and on a family of four it is usually several thousand dollars.
annual_gap_basic_to_liberal puts it in one place. Lead with it.

BE STRAIGHT ABOUT WHAT THESE FIGURES ARE. They are indicative planning
figures, not measured survey data and not a benchmark to hold anyone to.
Do not present them as official. If someone wants measured New Zealand
data, point them at the Household Economic Survey pages on the site
instead.

Args:
    members: One entry per person, e.g. ['adult_male', 'adult_female',
        'teen_11_17']. Between one and twelve.
    spend_level: 'basic', 'moderate' or 'liberal'.
    diet: 'standard', 'vegetarian', 'vegan', 'gluten_free', 'organic' or 'halal'.
    region: 'nz_average', 'auckland', 'wellington', 'christchurch',
        'hamilton', 'tauranga', 'dunedin', 'provincial' or 'rural_remote'.
    include_non_food: Add $25 a week for cleaning products and toiletries.

Returns:
    Weekly, monthly and annual budgets, all three spend levels, the annual
    gap between them, and the per-person weekly figure.

Input Schema

TableJSON Schema

Name	Required	Default
`diet`	No	standard
`region`	No	nz_average
`members`	Yes
`spend_level`	No	moderate
`include_non_food`	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 provided, the description carries the full burden of behavioral disclosure and meets it: it reveals the surprising trait that ALL THREE SPEND LEVELS COME BACK EVERY TIME, explains why annual_gap_basic_to_liberal is the headline figure, and warns that a teenager is not a child-sized cost. These behaviors are completely unobservable from the schema alone.

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 the length is earned given zero schema coverage and no annotations: query examples first, then the reasoning behind per-person input, then parameter semantics, then return values. Each paragraph serves a distinct purpose, though the rationale sentences could be trimmed slightly without losing meaning.

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 tool with 5 parameters, 0% schema description coverage, no annotations, and no output schema, this is exceptionally complete: it lists accepted values for members, diet, and region, defines spend levels and the gap metric, states the include_non_food assumption, and describes the return payload. Nothing an agent needs to invoke it correctly is missing.

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%, so the description must compensate — and it does, enumerating exact member type strings (child_5_10, teen_11_17, adult_male, adult_female, elderly_65), diet values, region values, and the $25/week meaning of include_non_food. The only gap is that the spend_level input's own accepttable values are implied through the three output levels rather than stated explicitly.

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 a weekly grocery budget for a New Zealand household.' It is clearly distinct from the 29 sibling NZ calculators by scoping to grocery budgeting, and it further defines its unique approach by building the household person by person rather than using an average per head.

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 an explicit 'Use for:' section with four concrete natural-language query examples ('am I spending too much on food'), giving the agent clear matching cues for invocation. It does not name sibling alternatives or state when-not-to-use, but no sibling tool overlaps with grocery budgeting, so the omission is minor.

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?