Skip to main content
Glama

australia can i retire

australia_can_i_retire
Read-only

Australia: can I retire at 60 with $500k in super (or any age and balance)? Year by year to 95 for one person or a couple: super guarantee and salary sacrifice (15% contributions tax), super from preservation age 60 into a tax-free account-based pension with the minimum drawdowns, the Age Pension from 67 under the income test (deeming, Work Bonus) and assets test (homeowner or not) from 20 September 2026, an optional UK State Pension (frozen in Australia), and tax (14% band from 2027-28, LITO, SAPTO, Medicare levy). Returns the age the money lasts to, bridge years to 67, wealth at retirement, the spending that lasts to 95, a retire-at-60/62/65 comparison and key years in today’s money.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "retireAge": "<retireAge>",
      "spending": "<spending>"
    },
    "name": "australia_can_i_retire"
  }
}

Input Schema

NameRequiredDescriptionDefault
ageNoYour age now
growthNoPension growth % a year after charges (an assumption)
salaryNoGross pay a year, AUD
savingsNoSavings and investments outside pensions, AUD
spendingYesHousehold spending a year in retirement after tax, today’s money, AUD
dbFromAgeNoAge the DB pension starts
dbPensionNoDefined benefit pension a year, AUD (0 if none)
homeownerNoOwns their home (Age Pension assets test)
householdNoHousehold
inflationNoInflation % a year
retireAgeYesAge you stop work
contribPctNoYour pension contributions, % of pay
partnerAgeNoPartner age now
pensionPotNoPension pots today, AUD
savingsAddNoAdded to savings each year until retirement, AUD
employerPctNoEmployer contributions, % of pay
otherAssetsNoCar, contents and other assets the assets test counts, AUD
partnerSalaryNoPartner gross pay a year, AUD
ukPensionWeeklyNoUK State Pension forecast a week in pounds (frozen in Australia; 0 if none)
partnerRetireAgeNoPartner retirement age
partnerPensionPotNoPartner pension pots, AUD

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint=false, and the description goes well beyond them by disclosing exactly which statutory machinery is simulated (15% contributions tax, preservation age 60, minimum drawdowns, income test with deeming and Work Bonus, assets test homeowner/non-homeowner, UK pension frozen, 14% band from 2027-28, LITO/SAPTO/Medicare levy). It does not state modelling caveats such as assumption sensitivity or that results are deterministic projections, which keeps it below a 5.

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

Conciseness3/5

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

The lead question is well front-loaded and no sentence is pure filler, but the body is one very long comma-spliced clause listing rules and outputs that is hard to scan for a 21-parameter tool. Restructuring the modelled rules and the return values into distinct sentences would preserve the content with far better readability.

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?

With 21 parameters, no output schema and no nested objects, this is a complex tool, and the description covers both inputs conceptually and outputs explicitly ('the age the money lasts to, bridge years to 67, wealth at retirement, the spending that lasts to 95, a retire-at-60/62/65 comparison and key years in today's money'). An agent has everything needed to decide applicability and interpret the response.

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 all 21 parameters are already documented and the baseline is 3. The description supplies useful domain framing that maps onto parameter clusters (e.g. 'UK State Pension (frozen in Australia)' for ukPensionWeekly, 'homeowner or not' for homeowner, preservation age for retireAge), but it never ties meaning to parameter names or explains interactions, so it adds only marginal value over the schema.

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 opens with a specific, scoped question ('Australia: can I retire at 60 with $500k in super ... Year by year to 95 for one person or a couple') that states the verb, resource, jurisdiction and time horizon. The country prefix and the enumerated rule set (super, Age Pension, UK State Pension, tax) make it trivially distinguishable from uk_can_i_retire, canada_can_i_retire and ireland_can_i_retire.

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?

It establishes clear usage context: Australian residents/couples modelling retirement adequacy, with an explicit 'or any age and balance' clause showing the scenario is configurable rather than fixed. It stops short of explicit when-not-to-use guidance or naming a sibling alternative (e.g. the UK or Canada equivalents for expats), so it is clear context without exclusions.

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.