Microburbs Australian Property Data

Suburb · Marital status

suburbs_area_stats_marital_status

Read-onlyIdempotent

Who is married, de facto, separated, divorced, widowed or never married, as counts and shares of adults, for every suburb and council area.

Coverage: About 10,500 suburbs and localities and 545 council areas across Australia, in all states and territories (areas with too few people or homes for reliable figures are left out); one snapshot at 10 August 2021. Current to 2021-08-10. Full description, field list and method: /v1/datasets/marital-status.

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": {
      "suburb_name": "<suburb_name>"
    },
    "name": "suburbs_area_stats_marital_status"
  }
}

Input Schema

Name	Required	Description
`to`	No	Last period to include, same formats as `from`.
`from`	No	First period to include: 2020, 2020-Q3, 2020-07 or 2020-07-01.
`fields`	No	Comma-separated subset of: total_aged_15_plus, married_count, married_pct, separated_count, separated_pct, divorced_count, divorced_pct, widowed_count, widowed_pct, never_married_count, never_married_pct, total_in_private_households_15_plus, partnered_registered_marriage_count, partnered_registered_marriage_pct, partnered_de_facto_count, partnered_de_facto_pct, not_partnered_count, not_partnered_pct. Omit for all.
`suburb_name`	Yes	Suburb name exactly as /v1/suburbs/list returns it, e.g. `Bondi` or `St Kilda (Vic.)`.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 13, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful non-annotation context: a single snapshot at 2021-08-10 (data currency), an explicit 5¢ per call price, and the exclusion of areas with too few people for reliable figures. It does not describe response shape or pagination, but the price and snapshot disclosures are real added value.

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 purpose is front-loaded in the first sentence, followed by compact coverage, currency and price blocks. Every line carries information; the bolded price and the documentation pointer are efficiently placed. Minor waste in restating the date twice ('one snapshot at 10 August 2021. Current to 2021-08-10.').

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 does state what is returned (counts and shares of adults by marital category) and points to the full field list and method at the dataset endpoint. Coverage limits, snapshot date and per-call price round out what an agent needs before calling. The remaining gap is the unresolved suburb-vs-council-area relationship with the LGA sibling.

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 documents every parameter including the field-subset string and date formats. The description adds one useful inference — that the data is a single snapshot at 10 August 2021 — implying the from/to range parameters cannot produce multiple periods. Beyond that it does not elaborate on parameter behavior, so the baseline 3 applies.

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 the exact resource (marital status counts and shares of adults) and the geographic scope (every suburb and council area, ~10,500 suburbs, 545 council areas). It is clearly distinguishable from the topical siblings (ancestry, religion, income) by its subject matter. It is slightly muddied by claiming to cover council areas as well, which overlaps the sibling lga_area_stats_marital_status without clarifying the difference.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not-to-use guidance, and the nearby lga_area_stats_marital_status alternative is never mentioned even though this tool claims the same council-area coverage. The only routing-adjacent information is the coverage note about areas being excluded for small populations, which is contextual rather than directive.

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 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?