Microburbs Australian Property Data

by au.com.microburbs

Overview Discussions Admin

Property · Most-recent rent observation

properties_rent_history_latest

Read-onlyIdempotent

Most-recent For Rent record.

Price: 10¢ per call.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`gnaf_id`	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": "One event in a property's market history — a sale, or a time it was\nadvertised for sale or for rent.\n\nRecords come from listing feeds, so this is the property's *advertised*\nhistory rather than a title/transfer register: a sale that never went to\nmarket may be absent. Records are returned newest first.",
-          "properties": {
-            "address": {
-              "anyOf": [
-                {
-                  "type": "string"
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "The property's address, title-cased. This is its current address as recorded in the national address file, repeated on every record — not the address text used in that particular listing, so it will not reflect a renumbering or a name change since.",
-              "title": "Address"
-            },
-            "date": {
-              "anyOf": [
-                {
-                  "type": "string"
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "When the event happened, as `YYYY-MM-DD`. For a `Sold` record this is the sale date; for `For Sale` / `For Rent` it is the date the listing appeared. Note for sold records: where the state land registry is the source this is the contract date rather than settlement, but sold dates sourced from listing portals are not guaranteed to be one or the other — treat it as accurate to the month, not the day.",
-              "title": "Date"
-            },
-            "price": {
-              "anyOf": [
-                {
-                  "type": "number"
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "The money figure attached to the event, in AUD. On `Sold` and `For Sale` records that is the whole price of the property; on `For Rent` it is the advertised rent, normally per week (the Australian convention) — but it is taken from the advertised text as-is and is not converted, so an agent who advertised monthly can leave a monthly figure here. Sanity-check rents that look ~4x too high. Null when the listing showed no number (e.g. 'Auction', 'Contact Agent').",
-              "title": "Price"
-            },
-            "type": {
-              "anyOf": [
-                {
-                  "type": "string"
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "Which kind of event this is. One of exactly three values: `'Sold'`, `'For Sale'` (advertised for sale, outcome not necessarily known) or `'For Rent'`. Determines how to read `price` and `date` above.",
-              "title": "Type"
-            }
-          },
-          "title": "HistoryRecord",
-          "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[HistoryRecord]",
-  "type": "object",
-  "x-fastmcp-top-level-schema": "ApiResponse_HistoryRecord_"
-}New value: +null

First observedSep 14, 2026

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description need not repeat safety. It does add a crucial behavioral detail: 'Price: 10¢ per call,' which is useful cost information. However, it does not describe the response format or whether the record includes all fields or just rent amount, leaving some behavioral transparency gaps.

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 extremely concise, consisting of a single clear sentence plus pricing. It is front-loaded with the core purpose. However, it is so minimal that it borders on under-specification rather than efficient conciseness, though the structure itself is clean.

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

Completeness2/5

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

Given there is no output schema, the description should clarify what the response contains, but it does not. It also fails to explain the parameter or any edge cases (e.g., what happens if no rent history exists). The tool is simple but the description leaves too much to the agent's inference, especially with no parameter documentation.

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

Parameters1/5

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

The only parameter, gnaf_id, has 0% schema description coverage. The description does not explain what gnaf_id is, how to obtain it, or any format details. Since the schema provides no help and the description adds nothing, the parameter semantics are essentially undocumented, making this a critical gap.

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 'Most-recent For Rent record,' which clearly identifies the operation: returning the latest rent record for a property. Combined with the title, it distinguishes itself from properties_rent_history (full history) and properties_sale_history_latest (sales version). The verb is implied but the resource is explicit enough.

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?

No guidance is provided on when to use this tool versus properties_rent_history or other property history tools. It does not state that this is for the single most recent observation, nor does it mention alternatives. The usage is implied by the name but not explicitly stated.

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?