Property · Recent sales within a radius
properties_comparables_recent_sales_nearbyRecent comparable sales in a small radius around the subject parcel.
Price: 4¢ per call.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| gnaf_id | Yes |
properties_comparables_recent_sales_nearbyRecent comparable sales in a small radius around the subject parcel.
Price: 4¢ 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 recent sale within the subject property's CMA search radius.",
- "example": {
- "address": "30 Arlington Street, Belmont North",
- "bath_count": 2,
- "bed_count": 3,
- "distance_m": 65,
- "dwelling_type": "house",
- "sale_date": "2024-08-12",
- "sale_price": 815000
- },
- "properties": {
- "address": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Street address.",
- "title": "Address"
- },
- "bath_count": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "description": "Bathrooms.",
- "title": "Bath Count"
- },
- "bed_count": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "description": "Bedrooms.",
- "title": "Bed Count"
- },
- "distance_m": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "description": "Distance from the subject property in metres.",
- "title": "Distance M"
- },
- "dwelling_type": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "house / unit / townhouse / ...",
- "title": "Dwelling Type"
- },
- "sale_date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "ISO date (YYYY-MM-DD).",
- "title": "Sale Date"
- },
- "sale_price": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "Sale price, AUD.",
- "title": "Sale Price"
- }
- },
- "title": "RecentSale",
- "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[RecentSale]]",
- "type": "object",
- "x-fastmcp-top-level-schema": "ApiResponse_list_RecentSale__"
-}New value: +nullDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a read-only, idempotent, non-destructive operation. The description adds pricing transparency (4¢ per call) but does not disclose radius size, result count, default ordering, or empty-result behavior. With annotations covering safety, this is adequate but thin.
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 short and front-loaded: first sentence states the data returned, second states the cost. No filler is present, though it is terse enough that key details are omitted.
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 should explain what a call actually returns, but it only says 'recent comparable sales' without clarifying fields, radius size, sorting, or limits. Given 80+ siblings, the lack of routing context also hurts completeness.
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?
The schema provides only a gnaf_id string with 0% coverage, and the description does not explain what gnaf_id is, where to obtain it, or how it maps to the 'subject parcel'. The phrase 'subject parcel' is an implicit tie, but it does not add meaningful parameter guidance.
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 that the tool returns recent comparable sales within a small radius of the subject parcel, which is a clear resource and scope. It does not explicitly name sibling alternatives or use a verb like 'returns', so it misses the top score.
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 given about when to prefer this tool over sibling comparables tools such as properties_comparables_all or properties_comparables_cma_comp_set. The phrase 'small radius' implies a use case, but no conditions, exclusions, or alternatives are provided.
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.