Microburbs Australian Property Data

by au.com.microburbs

Overview Discussions Admin

Suburb · Density

suburbs_development_density

Read-onlyIdempotent

Shown in the suburb report as the 'Density' card in the Development section.

Dwellings and people per km², plus the land area and counts behind them.

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

Input Schema

Name	Required	Description	Default
`suburb_name`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 15, 2026

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "available": {
-      "anyOf": [
-        {
-          "type": "boolean"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "description": "`false` on no-data responses. Omitted on success — branch on `data !== null` if you want a single discriminator.",
-      "title": "Available"
-    },
-    "data": {
-      "anyOf": [
-        {
-          "additionalProperties": true,
-          "description": "Dwelling and population density for a suburb, plus the land area and\ncounts behind it.\n\nTwo density measures ship together on purpose — they are computed on\ndifferent denominators and do not agree:\n\n* ``dwellings_per_km2`` / ``people_per_km2`` are the Microburbs\n  suburb-profile figures, and are what the Microburbs suburb report\n  headlines.\n* ``boundary_dwellings_per_km2`` / ``boundary_people_per_km2`` are the\n  plain whole-of-boundary ratios — exactly ``dwellings / area_km2`` and\n  ``population / area_km2``.\n\nThe profile figures are measured around the suburb's properties, not\nacross its whole polygon, so they differ from the boundary ratios in\neither direction (Belmont North: 1,002 vs 676; Bondi: 4,970 vs 6,193).\nPick the one that matches your question: profile density for \"how\nbuilt-up is the area people actually live in\", boundary density for\n\"how many dwellings per km² of suburb\".",
-          "example": {
-            "area_km2": 3.6314,
-            "area_level": "suburb",
-            "area_name": "Belmont North",
-            "boundary_dwellings_per_km2": 675.5,
-            "boundary_people_per_km2": 1729.4,
-            "density_level": "Mid",
-            "dwellings": 2453,
-            "dwellings_per_km2": 1002,
-            "people_per_km2": 2575,
-            "population": 6280
-          },
-          "properties": {
-            "area_km2": {
-              "anyOf": [
-                {
-                  "type": "number"
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "Land area of the ABS SAL boundary in km², summed from the equal-area mesh-block areas ABS publishes.",
-              "title": "Area Km2"
-            },
-            "area_level": {
-              "description": "Always 'suburb'.",
-              "title": "Area Level",
-              "type": "string"
-            },
-            "area_name": {
-              "description": "Suburb (SAL) name.",
-              "title": "Area Name",
-              "type": "string"
-            },
-            "boundary_dwellings_per_km2": {
-              "anyOf": [
-                {
-                  "type": "number"
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "`dwellings / area_km2` — the whole-of-boundary ratio.",
-              "title": "Boundary Dwellings Per Km2"
-            },
-            "boundary_people_per_km2": {
-              "anyOf": [
-                {
-                  "type": "number"
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "`population / area_km2` — the whole-of-boundary ratio.",
-              "title": "Boundary People Per Km2"
-            },
-            "density_level": {
-              "anyOf": [
-                {
-                  "type": "string"
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "Band the report labels `dwellings_per_km2` with: Low (<1,000), Mid (1,000–2,999), High (3,000+).",
-              "title": "Density Level"
-            },
-            "dwellings": {
-              "anyOf": [
-                {
-                  "type": "integer"
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "Census dwelling count across the suburb's mesh blocks.",
-              "title": "Dwellings"
-            },
-            "dwellings_per_km2": {
-              "anyOf": [
-                {
-                  "type": "integer"
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "Dwelling density from the Microburbs suburb profile — the figure the suburb report headlines. Measured around the suburb's properties, so it differs from `boundary_dwellings_per_km2`. Null for suburbs with no profile row (mostly rural / non-residential SALs).",
-              "title": "Dwellings Per Km2"
-            },
-            "people_per_km2": {
-              "anyOf": [
-                {
-                  "type": "integer"
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "Population density from the same suburb profile, on the same denominator as `dwellings_per_km2`.",
-              "title": "People Per Km2"
-            },
-            "population": {
-              "anyOf": [
-                {
-                  "type": "integer"
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "Census usual-resident population across the suburb's mesh blocks.",
-              "title": "Population"
-            }
-          },
-          "required": [
-            "area_name",
-            "area_level"
-          ],
-          "title": "SuburbDensity",
-          "type": "object"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "description": "The endpoint's payload, or `null` when Microburbs has no value."
-    },
-    "message": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "description": "Human-readable explanation. Omitted on success.",
-      "title": "Message"
-    },
-    "reason": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "description": "Machine-readable slug naming the no-data condition (e.g. `no_avm_for_GANSW704074813`). Stable per endpoint. Omitted on success.",
-      "title": "Reason"
-    }
-  },
-  "title": "ApiResponse[SuburbDensity]",
-  "type": "object",
-  "x-fastmcp-top-level-schema": "ApiResponse_SuburbDensity_"
-}New value: +null

First observedSep 14, 2026

TDQS

B3.2/5.0

Behavior4/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 by structured data. The description adds genuinely new behavioral context that annotations cannot express: the explicit 'Price: 5¢ per call' cost disclosure, which materially affects whether an agent should call this repeatedly. It does not cover return shape or any rate/limit behavior, keeping it short of 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?

Three short lines, front-loaded with what the card contains, followed by the verbatim cost. There is no filler or repetition, though the pricing sentence is set off as bold boilerplate rather than integrated, and the first sentence spends words on report placement that could be merged with the data description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read-only tool with no output schema and no nested objects, the definition covers the essential 'what do I get and what does it cost' angle. However, with no output schema the agent would benefit from knowing the shape of the response (metric names, units, whether the three measures come as separate fields), and the parameter remains undocumented, so it is adequate rather than complete.

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

Parameters2/5

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

The single required parameter suburb_name has 0% schema description coverage, so the description carries the full burden and largely fails to: it never says whether the value is a name, a postcode, a slug, or an ID, nor its format or case sensitivity. Only the word 'suburb' in the prose hints at the expected input, which is weaker than what an agent needs to construct a correct call.

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 concrete measures returned (dwellings and people per km², land area, and the underlying counts) and places the tool in the report as the 'Density' card, which is more specific than the title alone. It stops short of differentiating itself from close siblings such as suburbs_development_density_map or suburbs_development_profile, so the agent still has to infer which density variant it wants.

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 statement of when to use this tool versus alternatives, and no mention of prerequisites such as needing a valid suburb name or geocoded suburb. The existence of a sibling named suburbs_development_density_map makes the missing map-vs-card guidance a real gap, though the description does at least imply a tabular/card-level read.

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?