Skip to main content
Glama
Sign In

Microburbs Australian Property Data

by au.com.microburbs
OverviewDiscussionsAdmin

Suburb · Road crashes

suburbs_transport_road_crashes
Read-onlyIdempotent

Recorded road crashes by suburb and by council area per calendar year: fatal, serious-injury, other-injury and non-injury crashes, plus people killed and seriously injured, for every state and territory except the Northern Territory.

Coverage: NSW, Victoria, Queensland, South Australia, Tasmania and the ACT: 2016-2025 (Queensland to 2024); Western Australia 2021-2025. About 15,000 suburbs and 520 council areas. No Northern Territory data. Current to 2026-11-07. Full description, field list and method: /v1/datasets/road-crashes.

Price: 5¢ 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_transport_road_crashes"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoLast period to include, same formats as `from`.
fromNoFirst period to include: 2020, 2020-Q3, 2020-07 or 2020-07-01.
fieldsNoComma-separated subset of: casualty_crashes, fatal_crashes, serious_injury_crashes, other_injury_crashes, non_injury_crashes, people_killed, people_seriously_injured. Omit for all.
suburb_nameYesSuburb name exactly as /v1/suburbs/list returns it, e.g. `Bondi` or `St Kilda (Vic.)`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is covered. On top of that the description adds genuinely costly-to-discover facts: the geographic gaps (no Northern Territory data), per-state temporal coverage limits, dataset scale (~15,000 suburbs, 520 council areas), a currency date of 2026-11-07, a pointer to the full method at /v1/datasets/road-crashes, and the price of 5¢ per call.

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 scope is front-loaded in the first clause, followed by coverage limits and then method/price, which is a sensible order for an agent scanning for eligibility. It is dense but nearly every sentence carries decision-relevant content; the price line in bold is a small stylistic flourish but practically necessary.

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?

There is no output schema, and the description compensates by enumerating the measurable fields and the per-calendar-year grain, plus scale, coverage and cost. What it does not pin down is the shape of the response (e.g. one row per year per suburb, and how council-area figures are attached), which is a modest remaining gap for a tool returning a time series.

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%, so `from`, `to`, `fields` and `suburb_name` are already fully documented in the schema, including formats and the field subset list. The description adds no new parameter meaning — the crash-type nouns it lists merely echo the `fields` enumeration. Baseline 3 applies.

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 description states a specific resource (recorded road crashes), the unit of aggregation (suburb, with council-area breakdown), the time basis (per calendar year), and the exact metric set (fatal, serious-injury, other-injury, non-injury crashes plus people killed/seriously injured). That is far beyond a restatement of the title. It is only slightly muddied by claiming crashes are also reported 'by council area', which overlaps with the lga_transport_road_crashes sibling and leaves the boundary between the two implicit.

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?

Usage is conveyed indirectly through hard constraints rather than explicit routing: the agent learns the tool covers every state except the NT, with specific year windows per jurisdiction (QLD to 2024, WA from 2021), which lets it decide applicability. However, there is no statement of when to prefer this over lga_transport_road_crashes for council-level queries, nor a 'do not use for X' exclusion, so the agent must infer the alternative.

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 toolsInspect
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