suburbs_demographics_allWho lives in the suburb, from the census: population by age bracket and gender, and households by income bracket.
Two calls bundled, priced as the sum. Tenure, employment, family make-up, schooling and the rest of the Suburb - Demographics family are separate.
| Name | Required | Description | Default |
|---|---|---|---|
| suburb_name | Yes |
Changes observed during successful MCP inspections.
Output 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": [
- {
- "properties": {
- "age": {
- "anyOf": [
- {
- "items": {
- "additionalProperties": true,
- "description": "One row of demographic data — age bracket or income bracket. The\nshape varies per endpoint; common keys are always present, the rest\nare open (``extra=allow``) so a renamed sub-key doesn't break\nclients.",
- "example": {
- "age_bracket": "0-4",
- "area_level": "suburb",
- "area_name": "Belmont North",
- "gender": "females",
- "proportion": 0.0272
- },
- "properties": {
- "age_bracket": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Only on /demographics/age.",
- "title": "Age Bracket"
- },
- "area_level": {
- "description": "Always 'suburb'.",
- "title": "Area Level",
- "type": "string"
- },
- "area_name": {
- "description": "Suburb (SAL) name.",
- "title": "Area Name",
- "type": "string"
- },
- "gender": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Only on /demographics/age — 'males' / 'females' / 'persons'.",
- "title": "Gender"
- },
- "income_bracket": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Only on /demographics/income.",
- "title": "Income Bracket"
- },
- "median_income": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "description": "Only on /demographics/income.",
- "title": "Median Income"
- },
- "proportion": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "Share of the suburb in this bracket (0–1).",
- "title": "Proportion"
- }
- },
- "required": [
- "area_name",
- "area_level"
- ],
- "title": "DemographicRow",
- "type": "object"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "title": "Age"
- },
- "income": {
- "anyOf": [
- {
- "items": {
- "additionalProperties": true,
- "description": "One row of demographic data — age bracket or income bracket. The\nshape varies per endpoint; common keys are always present, the rest\nare open (``extra=allow``) so a renamed sub-key doesn't break\nclients.",
- "example": {
- "age_bracket": "0-4",
- "area_level": "suburb",
- "area_name": "Belmont North",
- "gender": "females",
- "proportion": 0.0272
- },
- "properties": {
- "age_bracket": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Only on /demographics/age.",
- "title": "Age Bracket"
- },
- "area_level": {
- "description": "Always 'suburb'.",
- "title": "Area Level",
- "type": "string"
- },
- "area_name": {
- "description": "Suburb (SAL) name.",
- "title": "Area Name",
- "type": "string"
- },
- "gender": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Only on /demographics/age — 'males' / 'females' / 'persons'.",
- "title": "Gender"
- },
- "income_bracket": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Only on /demographics/income.",
- "title": "Income Bracket"
- },
- "median_income": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "description": "Only on /demographics/income.",
- "title": "Median Income"
- },
- "proportion": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "Share of the suburb in this bracket (0–1).",
- "title": "Proportion"
- }
- },
- "required": [
- "area_name",
- "area_level"
- ],
- "title": "DemographicRow",
- "type": "object"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "title": "Income"
- }
- },
- "title": "DemographicsAll",
- "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[DemographicsAll]",
- "type": "object",
- "x-fastmcp-top-level-schema": "ApiResponse_DemographicsAll_"
-}New value: +nullDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds a genuinely non-structured behavioral trait: the call is a two-request bundle priced as the sum of both, which materially affects an agent's cost-aware selection. It stops short of noting return shape or latency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the content scope, then the bundling/pricing caveat and the exclusions. No filler; every clause carries selection-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 the job of sketching the return payload (age brackets/gender and income brackets) and the annotations carry safety. Coverage is solid for a simple one-param tool, though it could say more about the granularity of brackets or whether results are raw counts vs percentages.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the sole parameter, and the description never mentions suburb_name or its expected format. However, the parameter is a self-evident suburb identifier with 1 required param, so the gap is minor rather than crippling; baseline 3 for a trivially obvious single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Who lives in the suburb, from the census') and enumerates the exact content: population by age bracket and gender, households by income bracket. It also differentiates from siblings by naming what is not included (tenure, employment, family make-up, schooling), which is essential given nearby tools like suburbs_demographics_age and suburbs_demographics_income.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies the use case clearly: this is the bundled route when both age and income demographics are wanted, versus the single-topic siblings. It names the excluded family members rather than leaving them to inference, but never explicitly says 'use this instead of calling suburbs_demographics_age and suburbs_demographics_income separately', and gives no prerequisite guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.