Property · Sale & for-sale history
properties_sale_historyAll Sold + For Sale records, most-recent first.
Price: 30¢ per call.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| gnaf_id | Yes |
properties_sale_historyAll Sold + For Sale records, most-recent first.
Price: 30¢ per call.
| Name | Required | Description | Default |
|---|---|---|---|
| gnaf_id | 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": [
- {
- "items": {
- "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": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "The endpoint's payload, or `null` when Microburbs has no value.",
- "title": "Data"
- },
- "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[list[HistoryRecord]]",
- "type": "object",
- "x-fastmcp-top-level-schema": "ApiResponse_list_HistoryRecord__"
-}New value: +nullDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint). The description adds ordering (most-recent first) and the price per call, which are useful. However, it doesn't describe output format, pagination, or other behavioral traits. Given annotations handle 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 extremely concise with two short sentences. The primary function is front-loaded, and the cost is clearly stated. No wasted words.
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 parameter and no output schema, the description is minimal. It fails to explain what gnaf_id is, what the response looks like, or how it differs from similar tools. The annotations cover safety, but the description lacks essential context for correct 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% for the single parameter gnaf_id. The description does not mention this parameter at all, adding no meaning beyond the bare schema. The agent must infer that gnaf_id is a property identifier, which is not stated.
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 clearly states the tool returns all Sold and For Sale records, most-recent first, identifying the resource and scope. It doesn't explicitly differentiate from similar siblings like properties_history_all or properties_sale_history_latest, so it's not a 5.
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?
No guidance is provided on when to use this tool versus alternatives. Siblings such as properties_history_all, properties_sale_history_latest, and properties_rent_history exist, but the description offers no selection criteria or exclusions.
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.