Suburb · Supply pressure
suburbs_market_supply_pressureFor-sale listings per 100 dwellings (90 days) — per mesh block + suburb rollup.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| suburb_name | Yes |
suburbs_market_supply_pressureFor-sale listings per 100 dwellings (90 days) — per mesh block + suburb rollup.
| 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": [
- {
- "additionalProperties": true,
- "description": "Per-mesh-block supply pressure + suburb rollup.",
- "example": {
- "area_level": "suburb",
- "area_name": "Belmont North",
- "dwellings": 3980,
- "listings_90d": 42,
- "listings_per_100_dwellings": 1.06,
- "mbs": [
- {
- "dwellings": 54,
- "listings_90d": 0,
- "listings_per_100_dwellings": 0,
- "mb": "11205845900"
- }
- ]
- },
- "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"
- },
- "dwellings": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "description": "Total dwelling stock across the suburb's MBs.",
- "title": "Dwellings"
- },
- "listings_90d": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "description": "Total 90-day listings across the suburb's MBs.",
- "title": "Listings 90D"
- },
- "listings_per_100_dwellings": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "Suburb rollup: listings per 100 dwellings, last 90 days.",
- "title": "Listings Per 100 Dwellings"
- },
- "mbs": {
- "description": "Per-mesh-block breakdown.",
- "items": {
- "description": "Supply pressure for one mesh block.",
- "properties": {
- "dwellings": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "description": "Dwelling stock in the MB.",
- "title": "Dwellings"
- },
- "listings_90d": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "description": "Raw 90-day listings count.",
- "title": "Listings 90D"
- },
- "listings_per_100_dwellings": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "For-sale listings per 100 dwellings, last 90 days.",
- "title": "Listings Per 100 Dwellings"
- },
- "mb": {
- "description": "ABS mesh-block code (MB_CODE21).",
- "title": "Mb",
- "type": "string"
- }
- },
- "required": [
- "mb"
- ],
- "title": "SupplyPressureMb",
- "type": "object"
- },
- "title": "Mbs",
- "type": "array"
- }
- },
- "required": [
- "area_name",
- "area_level",
- "mbs"
- ],
- "title": "SupplyPressure",
- "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[SupplyPressure]",
- "type": "object",
- "x-fastmcp-top-level-schema": "ApiResponse_SupplyPressure_"
-}New value: +nullDoes 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 90-day lookback window and the per-mesh-block + suburb rollup granularity, which are useful behavioral details. However, it doesn't disclose what the response looks like, whether the metric is a ratio/percentage, or how missing data is handled. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core metric and adds the granularity detail. It is efficient and readable. It could arguably add a usage hint without becoming bloated, but as written it earns its place.
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?
For a tool with one required parameter, no output schema, and 0% schema description coverage, the description is thin. It tells the agent what the metric is but not how to invoke it correctly (parameter format), what the output structure is, or how this metric relates to the many other market supply tools. Given the large sibling set, more context is needed for reliable selection and invocation.
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%, and the only parameter is suburb_name with no description in the schema. The tool description does not explain what format suburb_name should take (e.g., 'Sydney' vs 'Sydney, NSW' vs 'sydney-nsw'), nor does it clarify whether it accepts a suburb ID or name. The description's mention of 'suburb rollup' implies the parameter is a suburb, but it adds no semantic detail beyond the parameter name itself.
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?
The description states a specific metric ('For-sale listings per 100 dwellings (90 days)') and the resource ('per mesh block + suburb rollup'). It clearly identifies what the tool computes. However, it doesn't explicitly distinguish it from closely related siblings like suburbs_market_stock_on_supply or suburbs_market_months_of_supply, so it's clear but not fully differentiated.
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?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools in the suburbs_market_* family (e.g., suburbs_market_stock_on_market, suburbs_market_months_of_supply, suburbs_market_days_on_market), an agent would need to infer which metric is most relevant. No exclusions or alternative routing are mentioned.
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.