Skip to main content
Glama

Microburbs Australian Property Data

Crime by mesh block — estimated rates and rank in suburb (by suburb) (beta)

suburbs_mesh_blocks_crime
Read-onlyIdempotent

Beta. The figures behind this topic have not been validated against an independent source, so it is not sold at the same confidence as the other mesh-block topics. Every response says beta: true and carries a beta_notice.

Is this place safe? Estimated crime rates for every mesh block in the suburb — all crime and eight types, per 100,000 residents a year — with where each block sits among the blocks in its suburb and nationally. From our mesh-block crime model, calibrated in November 2026 so each area's blocks add up to what police recorded there.

One entry per mesh block in the suburb under mesh_blocks, each with its mb_code, population and dwellings. Values only — the matching polygons come from /shapes/mesh-blocks.

Every field carries provenance — measured (at this block), measured_wider_area (measured for the SA1 or postcode and repeated on every block in it), estimate (our model) or not_recorded (not labelled yet) — plus how, one sentence on how the number was arrived at (empty when not_recorded).

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

Input Schema

NameRequiredDescriptionDefault
suburb_nameYes

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 only declare read-only, idempotent, non-destructive, so the description carries real weight here and delivers: unvalidated beta status returned as beta: true and a beta_notice, calibration in November 2026 so blocks sum to police records, and per-field provenance categories with their meanings. This is exactly the context structured fields cannot express.

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 beta caveat, then purpose, then response shape, then field semantics — the ordering is sound and most sentences earn their place. The beta warning is repeated in effect (prose plus the beta: true field), which is slightly redundant but defensible for a provisional dataset.

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 does the work of describing the mesh_blocks array, the per-entry fields (mb_code, population, dwellings), and the provenance/how conventions on every field. What is missing is the suburb_name input format and any routing against the similar crime siblings.

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 description coverage is 0% for the single suburb_name parameter, so the description must compensate and only partly does — it establishes that the scope is a suburb but never states the expected format (name vs code, case, matching behaviour) or points to geocode_suburb/suburbs_list for resolution. The provenance field semantics add value, but for parameters this is thin.

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 names a specific verb and resource — estimated crime rates for every mesh block in a suburb, all crime plus eight types per 100,000 residents a year, with within-suburb and national rank. It is clear what the tool returns, but it never distinguishes itself from the near-identical sibling suburbs_crime_by_mesh_block, so an agent cannot choose between them from the text alone.

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?

The framing question 'Is this place safe?' and the mesh-block granularity imply when the tool fits, and the pointer to /shapes/mesh-blocks for polygons tells the agent what this tool does not cover. However, no explicit when-to-use/when-not guidance is given, and the obvious alternatives (suburbs_crime_by_mesh_block, suburbs_crime_summary, suburbs_crime_breakdown) are never named or excluded.

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