Skip to main content
Glama

DwellDelta - Australian rent check and property indicators

Rents by place, Australia and NZ

property_rents
Read-onlyIdempotent

One place by whole name or postcode, no state needed - the only tool for NZ and for ACT and NT postcodes; an NSW, QLD, WA or SA total, an NSW or QLD council, a Victorian region or part of a name is in area_rents or vic_rents. Elsewhere in Australia: as those tools answer it, with their limits, sources and refusals. An NZ council or region: MBIE's median rent of new bonds for one month, in NZ$, provisional, no change on a year. An ACT or NT postcode, or a TAS one with too few bonds: interim ABS cover, not new-bond medians - the 2021 Census rent, the capital's rents index and sale prices, each with its period and flags. A name held in more than one place is listed, not chosen. For questions such as "median rent in Fremantle".

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": {
      "place": "<place>"
    },
    "name": "property_rents"
  }
}

Input Schema

NameRequiredDescriptionDefault
placeYesA suburb, locality, postcode or NZ council; a state may follow ("Richmond, VIC")
bedroomsNoAs area_rents (NSW and QLD only)
dwelling_typeNoAs area_rents (NSW and QLD only)

Output Schema

NameRequiredDescriptionDefault
staleYes
adviceYes
cadenceYes
sourcesYes
publisherYes
data_as_ofNo
stale_afterYes
retrieved_atYes
stale_reasonYes
period_due_byYes
period_overdueYes
resolved_placeYes
resolved_stateYes
server_versionYes
snapshot_builtNo
snapshot_originYes
period_overdue_reasonYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / place / description
      Previous value: -"A suburb, locality or postcode; a state may follow (\"Richmond, VIC\")"New value: +"A suburb, locality, postcode or NZ council; a state may follow (\"Richmond, VIC\")"
  2. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: MBIE new-bond medians for one month, provisional, NZ$, no year-on-year change; ABS interim cover for ACT/NT and thin TAS postcodes with the specific series used and their period/flags; and that an ambiguous name is listed rather than chosen. It stops short of describing response shape, but an output schema exists, so that omission is small.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is dense but every clause carries routing or data-provenance information, and the deciding constraint (this place, no state, siblings for everything else) is front-loaded. The case-to-outcome mapping structure suits a tool with several source regimes better than prose would.

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 three-parameter lookup with an output schema, it covers sources, periods, provisional flags, interim-coverage fallbacks, and ambiguity handling — everything an agent needs to call it and interpret the caveats. The only loose end is that bedrooms/dwelling_type support is only gestured at via 'as area_rents'.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the description earns above that by clarifying that whole names or postcodes work without a state and that duplicate names are returned as a list rather than resolved — behavior an agent cannot read off the schema. It says nothing about bedrooms or dwelling_type, deferring implicitly to area_rents, which leaves that pair of parameters to the schema's cross-reference.

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?

The resource and scope are unmistakable ('One place by whole name or postcode', rents) and the routing against area_rents and vic_rents is explicit, so an agent can tell it apart from every sibling. The opening is a verbless fragment, though — the plain 'this returns rent figures for a place' statement is carried by the title rather than the description text.

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

Usage Guidelines5/5

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

It names the conditions that select this tool over its siblings concretely: the only tool for NZ and for ACT/NT postcodes, while NSW/QLD/WA/SA totals, NSW/QLD councils, Victorian regions and partial names go to area_rents or vic_rents. That is explicit when-to-use and when-not-to-use with named alternatives.

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