Microburbs Australian Property Data

Aircraft noise zones (by suburb)

suburbs_mesh_blocks_aircraft_noise

Read-onlyIdempotent

How much of a suburb or city block sits inside the published aircraft-noise zones around Australian airports: share of addresses in each noise band, the loudest band, and whether the airport has a night curfew.

Coverage: About 250 suburbs and 4,700 blocks have at least one address inside a published zone (NSW, VIC, QLD, SA, WA, NT); about 1,700 more suburbs and 110,000 blocks within 20 km of such an airport are listed at 0%. Everywhere else, and Brisbane, Hobart and Canberra, is not listed. Current to 2026-10-19. Full description, field list and method: /v1/datasets/aircraft-noise.

One call returns every mesh block in the suburb.

Price: 20¢ 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": {
      "suburb_name": "<suburb_name>"
    },
    "name": "suburbs_mesh_blocks_aircraft_noise"
  }
}

Input Schema

Name	Required	Description	Default
`suburb_name`	Yes	Suburb name exactly as /v1/suburbs/list returns it, e.g. `Bondi` or `St Kilda (Vic.)`.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 13, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Beyond the read-only/idempotent annotations it discloses real operational facts: a per-call price of 20¢, the reference date (2026-10-19), that one call returns every mesh block in the suburb, and a pointer to `/v1/datasets/aircraft-noise` for field list and method. It doesn't discuss latency, pagination or result-size limits, but the coverage and billing disclosure is substantial context annotations cannot carry.

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?

Front-loaded with the core question it answers, then coverage, then price. The coverage paragraph is dense but every clause (0% listings, excluded cities, as-of date) prevents a wrong interpretation. Minor redundancy between the opening sentence and the coverage block.

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?

With no output schema, the description carries the return-value burden and does so in outline: band shares, loudest band, curfew status. Coverage boundaries, currency and cost are all supplied, and the external docs path covers the field list. An agent has enough to decide whether to call and to interpret empty results.

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

Parameters3/5

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

Schema coverage is 100% and the single `suburb_name` parameter already documents the `/v1/suburbs/list` matching rule and examples. The description adds only an indirect constraint via the 'One call returns every mesh block in the suburb' scoping note, which concerns output granularity rather than the parameter itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb-and-resource pair (share of addresses inside published aircraft-noise zones) and enumerates the returned quantities: per-band share, loudest band, night curfew. It is specific enough that an agent can distinguish it from sibling data tools without opening the schema.

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

Usage Guidelines4/5

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

Gives clear inclusion/exclusion conditions — only ~250 suburbs and 4,700 blocks actually have addresses in a zone, ~1,700 more are listed at 0%, and Brisbane, Hobart and Canberra are absent entirely — which tells an agent when a null result is expected rather than an error. It does not name an alternative tool for cases where this dataset has no coverage.

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

All Microburbs Australian Property Data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?