Skip to main content
Glama
Sign In

Microburbs Australian Property Data

by au.com.microburbs
OverviewDiscussionsAdmin

Taxpayers by occupation by postcode

postcodes_economy_taxpayer_occupation
Read-onlyIdempotent

How many people lodging a tax return in each postcode work in each of nine occupation groups (plus not stated), per income year 2018-19 to 2023-24.

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

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_occupation"
  }
}

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: occ_not_stated, occ_managers, occ_professionals, occ_technicians_trades, occ_community_personal_service, occ_clerical_admin, occ_sales, occ_machinery_drivers, occ_labourers, occ_apprentices_trainees. Omit for all.
postcodeYesFour-digit postcode, e.g. `2026`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds context annotations cannot carry: the data currency date (current to 2024-06-30), the geographic granularity (~2,530 postcodes), and, unusually valuably, a per-call price of 5¢, which lets the agent reason about call cost. It stops short of describing response shape or pagination, so a 4 rather than 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.

Conciseness4/5

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

The opening sentence is front-loaded with the core measure before any metadata, and the coverage/doc-link/price block is clearly separated. Every element carries information an agent can act on, including the price warning. It is slightly denser than needed in the second sentence grouping coverage, years and currency together, but there is 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 what comes back, and it does: a count per postcode per occupation group per income year. It also supplies currency date, geographic scope, a pointer to the full field list and method, and cost. The main residual gap is that it does not say whether results are returned per-group rows or wide columns, but for a simple read-only observation tool this is close to complete.

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 coverage is 100%, so the schema documents parameter formats itself, and that sets a baseline of 3. The description adds real meaning on top: it constrains the valid period range to income years 2018-19 through 2023-24, whereas the schema's `from`/`to` examples (2020-Q3, 2020-07, 2020-07-01) imply quarterly, monthly and daily granularity that this dataset does not actually support. It also confirms the nine occupation groups plus not-stated that populate the `fields` list.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: counts of people lodging tax returns in each postcode, broken down by nine occupation groups (plus not stated), for income years 2018-19 to 2023-24. That is precise enough for an agent to recognise the dataset without opening the schema. It does not explicitly contrast itself with nearby siblings such as postcodes_economy_taxpayer_age or lga_area_stats_occupation, so it falls short of a 5.

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 only implied by the coverage line ('About 2,530 postcodes; income years 2018-19 to 2023-24'), which tells the agent the data is postcode-level and annual, indirectly steering away from LGA/suburb or quarterly queries. There is no explicit when-to-use, when-not-to-use, or named alternative tool. This is adequate minimum-viable guidance rather than a routing instruction.

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