Suburb · Bedroom stats
suburbs_market_bedroom_statsRead-onlyIdempotent
House/unit price, sales volume, median bath/car/land, and stock mix per bedroom count.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| suburb_name | Yes |
Microburbs Australian Property Data
Schema Changelog
Changes observed during successful MCP inspections.
Changed1 schema field changed
- changed
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": [ - { - "additionalProperties": true, - "description": "Per-bedroom-count house/unit price, sales volume, medians and stock mix.", - "example": { - "area_level": "suburb", - "area_name": "Belmont North", - "bedrooms": [ - { - "bedrooms": 3, - "house_price": 952000, - "median_bath": 1, - "median_car": 2, - "median_land": 613, - "n_sales": 4364, - "pct_house": 88, - "pct_townhouse": 5, - "pct_unit": 1, - "unit_price": 705000 - } - ] - }, - "properties": { - "area_level": { - "description": "Always 'suburb' for these endpoints.", - "title": "Area Level", - "type": "string" - }, - "area_name": { - "description": "Suburb (SAL) name.", - "title": "Area Name", - "type": "string" - }, - "bedrooms": { - "description": "One row per bedroom count.", - "items": { - "description": "Price / sales / medians / stock mix for one bedroom count.", - "properties": { - "bedrooms": { - "description": "Bedroom count.", - "title": "Bedrooms", - "type": "integer" - }, - "house_price": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "description": "Latest smart-median asking price for a house of this bedroom count (AUD). Omitted when the suburb has no house listings at this bedroom count.", - "title": "House Price" - }, - "median_bath": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "description": "Median bathrooms.", - "title": "Median Bath" - }, - "median_car": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "description": "Median car spaces.", - "title": "Median Car" - }, - "median_land": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "description": "Median land size (sqm).", - "title": "Median Land" - }, - "n_sales": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "description": "Historical sales at this bedroom count.", - "title": "N Sales" - }, - "pct_house": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "description": "Share of stock that is houses (%).", - "title": "Pct House" - }, - "pct_townhouse": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "description": "Share of stock that is townhouses (%).", - "title": "Pct Townhouse" - }, - "pct_unit": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "description": "Share of stock that is units (%).", - "title": "Pct Unit" - }, - "unit_price": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "description": "Latest smart-median asking price for a unit of this bedroom count (AUD). Omitted when the suburb has no unit listings at this bedroom count.", - "title": "Unit Price" - } - }, - "required": [ - "bedrooms" - ], - "title": "BedroomStatsRow", - "type": "object" - }, - "title": "Bedrooms", - "type": "array" - } - }, - "required": [ - "area_name", - "area_level", - "bedrooms" - ], - "title": "BedroomStats", - "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[BedroomStats]", - "type": "object", - "x-fastmcp-top-level-schema": "ApiResponse_BedroomStats_" -}New value: +null
- First observed
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the specific data dimensions (price, sales volume, median bath/car/land, stock mix) but does not disclose aggregation method, time period, or whether results are per bedroom count across all dwelling types. With annotations covering safety, a 3 is appropriate.
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 description is a single compact sentence that front-loads the key data categories. It is efficient and contains no filler, though it could be slightly more explicit about the suburb_name parameter.
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 read-only, single-parameter tool, the description is mostly adequate, but it lacks detail on the output structure (no output schema) and the exact meaning of 'stock mix' and 'median bath/car/land' (e.g., are these per bedroom count or overall?). Given the large sibling set and no output schema, a bit more context would help.
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 0%, so the description must compensate. It names the single parameter implicitly (suburb_name) by saying 'per bedroom count' and 'per suburb' context, but it does not explain the expected format of suburb_name (e.g., 'Manly' vs 'Manly NSW'). With only one parameter, the gap is moderate, so a 3 is fair.
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 states a specific verb and resource: it reports house/unit price, sales volume, median bath/car/land, and stock mix per bedroom count for a suburb. It is clear enough to distinguish from most sibling tools, though it does not explicitly name a sibling alternative.
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?
The description implies usage for suburb-level bedroom statistics, but it does not state when to prefer this tool over alternatives like suburbs_market_all, suburbs_market_median_sale_price, or properties_basics_bed_count. No explicit when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.