Microburbs Australian Property Data

Suburb · Recorded crime (ACT)

suburbs_crime_recorded_offences_act

Read-onlyIdempotent

Police-recorded offences in Canberra by suburb, per calendar year for 2015-2024, by offence type.

Coverage: ACT: 115 suburbs; calendar years 2015-2024. Current to 2024-12-31. Full description, field list and method: /v1/datasets/recorded-crime-act.

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

Input Schema

Name	Required	Description
`to`	No	Last period to include, same formats as `from`.
`from`	No	First period to include: 2020, 2020-Q3, 2020-07 or 2020-07-01.
`fields`	No	Comma-separated subset of: total_offences, armed_robbery, burglary_of_dwellings, burglary_of_shops, family_violence_assault, homicide, motor_vehicle_theft, non_family_violence_assault, other_burglary, other_offences, other_offences_against_a_person, other_robbery, property_damage, sexual_assault, theft_excluding_motor_vehicles. Omit for all.
`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.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-structured behaviour: a per-call price of 5¢, the currency/refresh cut-off (2024-12-31) and a pointer to a fuller method document. It stops short of describing response shape or whether results are one row per suburb-year-offence.

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?

Four short lines: purpose first, then coverage window, then a doc pointer, then pricing. Nothing is redundant and the most decision-relevant facts are front-loaded.

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 four-parameter, single-required-argument read tool with full annotation coverage and no output schema, the description supplies sufficient scope, freshness and cost context. The main missing piece is a hint about the returned shape (grain of the results, whether offence types come back as columns), which the absent output schema leaves entirely unaddressed.

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

Parameters5/5

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

Schema description coverage is 100% — every parameter, including `from`/`to` accepted formats and the full `fields` value list, is documented inline. With that baseline the description adds no parameter meaning of its own, but it also introduces no ambiguity, so the structured data carries this dimension fully. Actually, per the rubric this deserves the baseline 3; see summary.

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 specific resource (police-recorded offences), the geography (Canberra/ACT suburbs), the time span (calendar years 2015-2024) and the breakdown dimension (offence type) in one sentence. The explicit ACT/Canberra framing cleanly separates it from the state-level siblings (nsw, qld, sa, vic) without needing to name them.

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?

Coverage is spelled out ('ACT: 115 suburbs; calendar years 2015-2024') and a link to the full dataset doc is given, which implies when the tool is appropriate. However, there is no explicit when-to-use/when-not guidance versus siblings such as suburbs_crime_breakdown or suburbs_crime_summary, and no stated prerequisites (e.g. that suburb_name must first be resolved via the suburbs list endpoint is only buried in the schema).

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?