Microburbs Australian Property Data

Public transport access by mesh block (by suburb)

suburbs_mesh_blocks_public_transport_access

Read-onlyIdempotent

Distance to the nearest stop and station, share of homes within a short walk, and weekday service within 400 m, for every residential mesh block in Victoria, South East Queensland, Perth, Adelaide, Tasmania and Darwin.

Coverage: Victoria (trains, trams, buses, coaches), South East Queensland, the Perth region and the towns its bus network serves, Adelaide and its regional services, Tasmania, and Darwin. Not covered: New South Wales, the ACT, the rest of Queensland and the Northern Territory outside Darwin. A block is included when its suburb is included, i.e. when it is in a covered state and within 25 km of a stop; inside that area a suburb with no service shows real zeros. Current to 2026-11-06. Full description, field list and method: /v1/datasets/public-transport-block.

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_public_transport_access"
  }
}

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.4/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses a per-call price (20¢), a data currency date (2026-11-06), the exact geographic inclusion boundary, the semantics of zero values for unserved suburbs, and a pointer to the full field list and method. These are the details that actually change how an agent budgets and interprets calls, and none of them are recoverable from the annotations.

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?

The metric list and granularity statement are front-loaded where they matter most, and the pricing and coverage blocks are clearly segmented. It runs long for a one-parameter tool — the coverage sentence repeats the state list already given in the opening paragraph — but no paragraph is genuinely idle.

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

Completeness5/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 burden of describing returns and does so: it enumerates the three returned measures and defers the full field list to a documented endpoint. Coverage limits, currency, and the zero-value case are all present, so an agent has everything needed to call it and read the response correctly.

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 parameter's own description already explains that the name must match `/v1/suburbs/list` output exactly, including the disambiguation convention like `St Kilda (Vic.)`. The prose adds no further guidance on the single `suburb_name` argument, so the schema is doing essentially all of the work.

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?

The opening sentence names the concrete metrics (distance to nearest stop/station, share of homes within a short walk, weekday service within 400 m) and pins the unit of analysis to the residential mesh block, with a final line stating 'One call returns every mesh block in the suburb.' That granularity statement alone separates it from suburb-level transport siblings without needing to open a 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?

Coverage and exclusion rules are explicit — New South Wales, the ACT, the rest of Queensland and non-Darwin NT are called out as not covered, and the 25 km inclusion rule plus the 'real zeros' caveat tells the agent when an empty-looking result is still valid. It stops short of naming a specific alternative tool for out-of-coverage queries, so an agent must infer which sibling to fall back to.

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?