Microburbs Australian Property Data

Count matching suburbs

suburbs_finder_count

Read-onlyIdempotent

How many suburbs match the filter, without paying per row. 5c.

Use this to size a result before searching: /search is capped at 25 rows per call, so total here tells you how many offset pages you need.

Price: 5¢ per call.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "suburbs_finder_count"
  }
}

Input Schema

Name	Required	Description	Default
`filter`	No	Range filter `fieldKey:min..max` (repeatable). Valid fieldKeys: medianHousePrice, grossYield, medianRent, growthForecast4yr, growth10yrCagr, growth3yrCagr, rentGrowth3yr, soldAtLossPct, daysOnMarket, vacancyRate, unitMedianPrice, unitGrossYield, unitMedianRent, unitGrowthForecast4yr, unitGrowth10yrCagr, unitGrowth3yrCagr, unitRentGrowth3yr, unitSoldAtLossPct, unitDaysOnMarket, unitVacancyRate, stockOnMarket, monthsOfInventory, landValuePerSqm, lifestyleScore, safetyScore, hipScore, affluenceScore, renters, distanceCbdKm, publicHousingPct, overseasBornPct, welfareReliancePct, unemploymentPct, singleParentsPct, familyHouseholdsPct, privateSchoolPct, medianIncomeWeekly, communityDepthIndex, premiumRenovationIndex, homeOfficeIndex, tranquilityIndex, innovationEconomyIndex, alternativeLivingIndex, investorConcentration, negativeGearingExposure, mortgageStress. Fields with unit `percent` are FRACTIONS, not 0-100: 0.06 means 6%, so a gross yield of at least 6% is `grossYield:0.06..`. Apartment/unit metrics are the `unit`-prefixed keys (unitMedianPrice, unitGrossYield, unitMedianRent, …); the unprefixed market keys are houses. Unit data only exists where a suburb has a real unit market — coverage runs ~13-54% of suburbs depending on the field, so a unit filter implicitly excludes house-only suburbs.
`states`	No	Comma-separated states (names or abbreviations), e.g. `VIC`.
`regions`	No	Comma-separated EXACT SA4 region names — call GET /v1/suburbs/finder/regions for the list. A metro name like `Melbourne` alone will NOT match.
`property_type`	No	Legacy flag: 'unit' re-points the ten unprefixed house-market keys (medianHousePrice, grossYield, ...) at their unit column. It does NOT affect the explicit `unit`-prefixed keys, which are always units. Prefer the `unit` keys — they are visible in /fields and can be mixed with house keys in one query.	house

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 13, 2026

changedInput schema / properties / filter / description

Previous value: -"Range filter `fieldKey:min..max` (repeatable). Valid fieldKeys: medianHousePrice, grossYield, medianRent, growthForecast4yr, growth10yrCagr, growth3yrCagr, rentGrowth3yr, soldAtLossPct, daysOnMarket, vacancyRate, unitMedianPrice, unitGrossYield, unitMedianRent, unitGrowthForecast4yr, unitGrowth10yrCagr, unitGrowth3yrCagr, unitRentGrowth3yr, unitSoldAtLossPct, unitDaysOnMarket, unitVacancyRate, stockOnMarket, monthsOfInventory, landValuePerSqm, lifestyleScore, safetyScore, hipScore, affluenceScore, renters, distanceCbdKm, publicHousingPct, overseasBornPct, welfareReliancePct, unemploymentPct, singleParentsPct, familyHouseholdsPct, privateSchoolPct, medianIncomeWeekly, communityDepthIndex, premiumRenovationIndex, homeOfficeIndex, tranquilityIndex, innovationEconomyIndex, alternativeLivingIndex, investorConcentration, negativeGearingExposure, mortgageStress. Apartment/unit metrics are the `unit`-prefixed keys (unitMedianPrice, unitGrossYield, unitMedianRent, …); the unprefixed market keys are houses. Unit data only exists where a suburb has a real unit market — coverage runs ~13-54% of suburbs depending on the field, so a unit filter implicitly excludes house-only suburbs."New value: +"Range filter `fieldKey:min..max` (repeatable). Valid fieldKeys: medianHousePrice, grossYield, medianRent, growthForecast4yr, growth10yrCagr, growth3yrCagr, rentGrowth3yr, soldAtLossPct, daysOnMarket, vacancyRate, unitMedianPrice, unitGrossYield, unitMedianRent, unitGrowthForecast4yr, unitGrowth10yrCagr, unitGrowth3yrCagr, unitRentGrowth3yr, unitSoldAtLossPct, unitDaysOnMarket, unitVacancyRate, stockOnMarket, monthsOfInventory, landValuePerSqm, lifestyleScore, safetyScore, hipScore, affluenceScore, renters, distanceCbdKm, publicHousingPct, overseasBornPct, welfareReliancePct, unemploymentPct, singleParentsPct, familyHouseholdsPct, privateSchoolPct, medianIncomeWeekly, communityDepthIndex, premiumRenovationIndex, homeOfficeIndex, tranquilityIndex, innovationEconomyIndex, alternativeLivingIndex, investorConcentration, negativeGearingExposure, mortgageStress. Fields with unit `percent` are FRACTIONS, not 0-100: 0.06 means 6%, so a gross yield of at least 6% is `grossYield:0.06..`. Apartment/unit metrics are the `unit`-prefixed keys (unitMedianPrice, unitGrossYield, unitMedianRent, …); the unprefixed market keys are houses. Unit data only exists where a suburb has a real unit market — coverage runs ~13-54% of suburbs depending on the field, so a unit filter implicitly excludes house-only suburbs."

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": [
-        {
-          "description": "How many suburbs match the filter — without paying for the rows.",
-          "example": {
-            "total": 126
-          },
-          "properties": {
-            "total": {
-              "description": "Suburbs matching every range filter (after the hard exclusions).",
-              "title": "Total",
-              "type": "integer"
-            }
-          },
-          "required": [
-            "total"
-          ],
-          "title": "CountResponse",
-          "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[CountResponse]",
-  "type": "object",
-  "x-fastmcp-top-level-schema": "ApiResponse_CountResponse_"
-}New value: +null

First observedSep 14, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds genuinely new behavior context: the 5¢ per-call price (stated twice) and the interaction with the 25-row search cap. It does not say what the response object looks like beyond implying a `total` field, nor whether filters are applied identically to search.

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?

Four short lines, front-loaded with the core purpose and followed by the sizing rationale and price. The cost is stated twice ('without paying per row. 5c.' and 'Price: 5¢ per call.'), a minor redundancy that could be folded into one statement.

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?

For a 4-optional-parameter read-only count with no output schema, the description supplies the two things an agent most needs to call it correctly: what it returns conceptually (`total`) and its cost/pagination role relative to search. What remains unsaid about filtering is fully carried by an exceptionally detailed schema.

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% and the schema is unusually rich, spelling out fraction units, exact SA4 region names, and the unit-prefix versus legacy property_type interaction. The description adds no parameter-level meaning at all, 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 verb and resource ('How many suburbs match the filter') and immediately frames it as a count-only operation 'without paying per row', which separates it from the row-returning search tool. An agent can tell exactly what this returns and why it differs from a sibling without opening any schema.

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

Usage Guidelines5/5

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

Gives an explicit when-to-use rule: call this to size a result before searching, because /search is capped at 25 rows per call and `total` determines how many `offset` pages are needed. The alternative (search) and the condition selecting it are both named, leaving nothing to inference.

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?