Suburb · Median sale price
suburbs_market_median_sale_priceLatest median sale price for the suburb.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| suburb_name | Yes |
suburbs_market_median_sale_priceLatest median sale price for the suburb.
| 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": "Latest median sale price by property type (AUD).",
- "example": {
- "area_level": "suburb",
- "area_name": "Belmont North",
- "as_of": "2026-05-24",
- "house": 1160000,
- "unit": 573000
- },
- "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"
- },
- "as_of": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Date of the most recent observation (YYYY-MM-DD).",
- "title": "As Of"
- },
- "house": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "Median sale price for houses (AUD).",
- "title": "House"
- },
- "unit": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "Median sale price for units (AUD).",
- "title": "Unit"
- }
- },
- "required": [
- "area_name",
- "area_level"
- ],
- "title": "MedianSalePrice",
- "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[MedianSalePrice]",
- "type": "object",
- "x-fastmcp-top-level-schema": "ApiResponse_MedianSalePrice_"
-}New value: +nullDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds minimal behavior context (only that it is the latest price), but doesn't disclose what happens if suburb is invalid, whether data is ASX or CoreLogic based, or if there are any data licensing restrictions. 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?
A single sentence, no redundancy, and the key word 'latest' is front-loaded with 'median sale price'. Perfectly concise for what it claims to do.
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 simple 1-param tool with no output schema, it is minimally adequate. It doesn't explain return value structure (e.g., numeric vs object) or units (AUD?), but given the simplicity, the gaps are moderate. The sibling set is huge, and more context would help disambiguate from series and other market tools.
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%, so the description must compensate for the single parameter 'suburb_name'. It doesn't clarify format (e.g., exact name spelling, case sensitivity, need for underscores like 'north_sydney'), which is critical. It does implicitly tie the parameter to the tool's purpose, but no real added meaning beyond the schema.
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?
States a clear verb ('median sale price') and resource ('suburb'), with enough specificity to distinguish from median rent and price growth tools. However, it doesn't mention that it returns only the latest value, which is implied by the title but could be clearer given the series tool exists.
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?
Implies usage for checking a suburb's current median sale price, but no explicit guidance on when to use this over the series version or other price-related tools. It doesn't mention that the series tool should be used for historical trends, leaving the agent to infer the difference.
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.