suburbs_lifestyle_poi_impactsWhat the absence of petrol stations, fast food and bottle shops near sold properties was worth.
| 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": "What the absence of petrol / fast food / bottle shops near sold\nproperties was worth in this suburb.",
- "example": {
- "area_level": "suburb",
- "area_name": "Castlecrag",
- "drivers": [
- {
- "coverage_pct": 100,
- "detail": "100% of 9 recent sales in Castlecrag were at properties with no petrol station nearby. Those sales cleared about $184,500 more than comparable suburbs with petrol stations, equivalent to 4.1% of the $4,500,000 median price here.",
- "label": "No petrol station nearby",
- "pct_of_median": 4.1,
- "premium_dollars": 184500
- }
- ],
- "median_price": 4500000,
- "n_sales": 9,
- "total_premium": 263000
- },
- "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"
- },
- "drivers": {
- "description": "Drivers, largest premium first.",
- "items": {
- "additionalProperties": true,
- "description": "One amenity-absence price driver.",
- "properties": {
- "coverage_pct": {
- "description": "Share of recent sales the absence applies to (%).",
- "title": "Coverage Pct",
- "type": "number"
- },
- "detail": {
- "description": "Plain-English explanation of the driver.",
- "title": "Detail",
- "type": "string"
- },
- "label": {
- "description": "Driver label (e.g. 'No petrol station nearby').",
- "title": "Label",
- "type": "string"
- },
- "pct_of_median": {
- "description": "Premium as a share of the median price (%).",
- "title": "Pct Of Median",
- "type": "number"
- },
- "premium_dollars": {
- "description": "Estimated price premium attributable to the absence (AUD).",
- "title": "Premium Dollars",
- "type": "integer"
- }
- },
- "required": [
- "label",
- "premium_dollars",
- "coverage_pct",
- "pct_of_median",
- "detail"
- ],
- "title": "PoiImpactDriver",
- "type": "object"
- },
- "title": "Drivers",
- "type": "array"
- },
- "median_price": {
- "description": "Median sale price across those sales (AUD).",
- "title": "Median Price",
- "type": "integer"
- },
- "n_sales": {
- "description": "Recent sales in the analysis window.",
- "title": "N Sales",
- "type": "integer"
- },
- "total_premium": {
- "description": "Combined absence premium across all drivers (AUD).",
- "title": "Total Premium",
- "type": "integer"
- }
- },
- "required": [
- "area_name",
- "area_level",
- "n_sales",
- "median_price",
- "total_premium",
- "drivers"
- ],
- "title": "LifestylePoiImpacts",
- "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[LifestylePoiImpacts]",
- "type": "object",
- "x-fastmcp-top-level-schema": "ApiResponse_LifestylePoiImpacts_"
-}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, covering the safety profile. The description adds the meaning of the metric but does not disclose output format, units, or behavior on missing data. It does not contradict annotations.
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 without extraneous words. It is front-loaded with the subject matter, but the phrasing 'was worth' is slightly awkward and could be clearer.
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?
With no output schema, the description must explain what the tool returns. It only defines the metric without stating the type, scale, or interpretation. For a simple one-parameter read-only tool, this is minimal but insufficient for an agent to confidently use the result.
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%. The description does not mention the 'suburb_name' parameter or any expected format, so an agent must infer from the parameter name alone. This violates the requirement that the description compensate for low schema coverage.
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 the metric being returned: the worth of absence of petrol stations, fast food, and bottle shops near sold properties. This distinguishes it from sibling tools like suburbs_lifestyle_pois, which would likely report the amenities themselves. However, it lacks an explicit verb like 'calculates' or 'returns', so it reads as a result rather than an action.
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 such as suburbs_lifestyle_pois or suburbs_market_* tools. The description does not mention prerequisites, data availability, or typical use cases.
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.