Skip to main content
Glama

Microburbs Australian Property Data

Property · CMA — single best comparable

properties_comparables_cma_single_comp
Read-onlyIdempotent

Single best comparable from the CMA set (the most alike: a same-building sale first, then the nearest similar sale).

Price: 10¢ per call.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "gnaf_id": "<gnaf_id>"
    },
    "name": "properties_comparables_cma_single_comp"
  }
}

Input Schema

NameRequiredDescriptionDefault
gnaf_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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 comparable sale row.",
      -          "example": {
      -            "bathrooms": 2,
      -            "bedrooms": 4,
      -            "date_sold": "2024-07-13",
      -            "dist_score": 6.319769313849382,
      -            "garage_spaces": 2,
      -            "gnaf_pid": "GAACT714923950",
      -            "latitude": -35.38013684,
      -            "longitude": 149.06828089,
      -            "price": 815000,
      -            "property_type": "house",
      -            "sal": "Kambah",
      -            "state": "ACT",
      -            "street": "8 SHIPARD PL"
      -          },
      -          "properties": {},
      -          "title": "CmaComp",
      -          "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[CmaComp]",
      -  "type": "object",
      -  "x-fastmcp-top-level-schema": "ApiResponse_CmaComp_"
      -}New value: +null
  2. First observed

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds genuinely useful non-structured context: the per-call price of 10¢ and the deterministic ordering used to pick the comp. It does not mention what happens when no comparable exists, which matters for a tool that promises exactly one result.

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?

Two tight sentences: purpose and selection rule first, cost signalled in bold afterwards. Little waste, though the pricing line could arguably be moved to the end of a longer doc; here it fits fine.

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

Completeness4/5

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

For a single-parameter read with annotations covering the safety profile and a documented selection rule, this is close to sufficient; there is no output schema, so a phrase on the returned shape or the no-match case would complete it. The main gap is not the tool's behaviour but the undocumented input.

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

Parameters2/5

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, so the description carries the burden and does not mention the parameter at all — not its format, not that it is an address/property identifier, not what happens if it is unknown. An agent must infer everything about the input.

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?

States a specific resource (the single best comparable from the CMA set) and even defines the selection rule: same-building sale first, then nearest similar sale. That distinguishes it from the sibling comp_set, though the differentiation is implicit rather than naming the sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The one-comparable scope implies a use case (a headline/exhibit comp rather than a full analysis), but there is no explicit when-to-use-this vs. the comp-set tool statement. The stated tie-breaking order is helpful selection logic, not routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources