Skip to main content
Glama

Australian take-home pay

take_home_pay
Read-onlyIdempotent

Take-home pay in Australia for a salary or hourly rate, for 2025-26 or 2026-27. Returns gross pay, PAYG tax withheld, net pay and the employer's 12% super for each week, fortnight and month and for the year, plus a basic estimate of the year's tax and refund that assumes no deductions or other income. Use it for questions like 'how much do I take home on $85,000'. For one specific pay with declaration details use payg_withholding; for a tax return estimate with deductions, other income, family or seniors offsets use annual_tax_estimate; to go from a target take-home to a salary use salary_for_take_home. Amounts in AUD. Read-only and deterministic; no network calls.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "take_home_pay"
  }
}

Input Schema

NameRequiredDescriptionDefault
salaryNoAnnual salary in AUD, excluding super unless salaryIncludesSuper is true, e.g. 85000. Give salary or hourlyRate, not both.
taxYearNoAustralian financial year (1 July to 30 June) whose withholding tables to use. Default 2026-27.
studyLoanNoHas a HELP, VSL, SSL or other study and training support loan. Default false.
hourlyRateNoHourly rate in AUD excluding super, including any casual loading, e.g. 35.5.
tfnProvidedNoEmployee gave their tax file number. Default true. False applies the no-TFN rate.
hoursPerWeekNoHours a week for hourlyRate. Default 38 (full time).
foreignResidentNoForeign resident for tax purposes. Default false.
taxFreeThresholdNoTax-free threshold claimed with this employer. Default true (main job). Use false for a second job.
salaryIncludesSuperNoThe salary is a total package that includes the 12% super guarantee. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the bar is lower; the description nonetheless adds that the refund figure is a basic estimate assuming no deductions or other income, which is a material behavioral caveat. 'Deterministic; no network calls' partly restates openWorldHint=false, and it doesn't say what happens if both salary and hourlyRate are supplied, but the assumption disclosure goes beyond structured data.

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?

Front-loaded with what it computes and returns, then routing, then a caveat and unit note; every sentence carries information. It is a dense single paragraph and slightly long, but no sentence is filler.

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?

With nine optional parameters and no output schema, the description does the necessary work of enumerating the returned values and flagging the refund estimate's assumption. It stops short of describing edge-case behavior (e.g., neither salary nor hourlyRate given) and the per-pay breakdown's caveats, but an agent has enough to call it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter is already documented (tfnProvided, studyLoan, foreignResident, salaryIncludesSuper, hoursPerWeek, etc.). The description adds only the aggregate notion that the 12% super is included and that amounts are in AUD, without elaborating on individual flags; baseline 3 applies when the schema does the heavy lifting.

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?

States a specific resource (Australian take-home pay) with scope qualifiers: salary or hourly rate, tax years 2025-26/2026-27, and the outputs returned (gross, PAYG withheld, net, 12% super, per week/fortnight/month/year). It is unmistakably distinct from siblings like payg_withholding and salary_for_take_home.

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?

Gives a concrete use-case example ('how much do I take home on $85,000') plus explicit routing: payg_withholding for a single pay with declaration details, annual_tax_estimate for returns with deductions/offsets, salary_for_take_home for reverse calculation. Each alternative is paired with the condition that selects it.

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.