Skip to main content
Glama
Sign In

Microburbs Australian Property Data

by au.com.microburbs
OverviewDiscussionsAdmin

Taxpayers by age band by postcode

postcodes_economy_taxpayer_age
Read-onlyIdempotent

How many people lodging a tax return in each postcode are in each of six age bands, per income year 2016-17 to 2023-24.

Coverage: About 2,530 postcodes; income years 2016-17 to 2023-24. Current to 2024-06-30. Full description, field list and method: /v1/datasets/taxpayer-age.

Price: 5¢ per call.

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": {
      "postcode": "<postcode>"
    },
    "name": "postcodes_economy_taxpayer_age"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoLast period to include, same formats as `from`.
fromNoFirst period to include: 2020, 2020-Q3, 2020-07 or 2020-07-01.
fieldsNoComma-separated subset of: age_under_25, age_25_34, age_35_44, age_45_54, age_55_64, age_65_plus. Omit for all.
postcodeYesFour-digit postcode, e.g. `2026`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile needs no restatement. The description adds genuinely useful behavior beyond them: the row-coverage bound (~2,530 postcodes), the currency date (2024-06-30), and a per-call price of 5¢, which is the kind of cost signal an agent should know before looping over many postcodes.

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?

Front-loaded with the measure, then a compact Coverage block, then a documentation pointer and the price in bold. Every line carries information an agent can act on, with no 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 no output schema, the description must convey the return shape, and it does so adequately (counts per age band per postcode per income year). The only residual gap is the exact row granularity and how the six age-band columns are named in the response, which is left to the linked dataset documentation.

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 the schema already explains `postcode`, `from`/`to` period formats and the `fields` subset. The description's phrase 'six age bands' corroborates the field list but adds no syntax or defaulting guidance beyond it, so the baseline 3 applies.

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 precise measure (count of people lodging a tax return), the unit of aggregation (postcode), the breakdown (six age bands) and the time span (2016-17 to 2023-24). This cleanly separates it from the sibling postcodes_economy_taxpayer_occupation, which breaks the same population down by occupation instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: an agent can infer this is the tool for age-band breakdowns at postcode level, and the coverage line (about 2,530 postcodes, 2016-17 to 2023-24) effectively rules out out-of-scope requests. However, it never says when to prefer a sibling such as suburbs_demographics_age or postcodes_economy_income_distribution, nor what to do if the requested postcode or year falls outside coverage.

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

All Microburbs Australian Property Data toolsInspect
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