Skip to main content
Glama

Microburbs Australian Property Data

by au.com.microburbs
OverviewDiscussionsAdmin

List suburbs

suburbs_list
Read-onlyIdempotent

List Australian suburbs (SALs). Always returns {suburb, state} per row so SAL-name collisions across states are unambiguous.

With no filter you get the first 1000 suburbs alphabetically (browser-renderable preview). Pass any of the filters to narrow: state / lga / sa4 / sa3 / postcode / q (name search). Filters combine (AND). Flat cost regardless of how many rows come back.

Name search (q) is typo-tolerant. It tries an exact match, then substring, then a fuzzy near-miss, and returns match (exact / contains / fuzzy) and score on every row so you can see which happened.

Always tell the user which suburb you resolved to, and its state, before quoting numbers for it. A fuzzy match is a suggestion, not a confirmation — rokeby is one letter from Kokeby in Western Australia and Rokeby exists in both Tasmania and Victoria. If more than one candidate is plausible, ask rather than pick.

When q is combined with state, the state is a preference, not a filter: in-state candidates rank first, but a suburb of that name in another state is still returned rather than hidden, so a near-miss becomes "Seaview is in Victoria, not Tasmania" instead of "no data". Every other filter stays a strict AND.

Free.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoSuburb-name search. Matches exactly, then by substring, then by fuzzy near-miss so a typo still resolves ('devenport' -> Devonport). Each row comes back with `match` and `score` saying how it was found.
lgaNoFilter by Local Government Area name.
sa3NoFilter by SA3 name.
sa4NoFilter by SA4 name.
stateNoFilter by state / territory (e.g. NSW, VIC, 'New South Wales').
postcodeNoFilter by 4-digit postcode (POA).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "available": {
-      "anyOf": [
-        {
-          "type": "boolean"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "description": "`false` on no-data responses. Omitted on success — branch on `data !== null` if you want a single discriminator.",
-      "title": "Available"
-    },
-    "data": {
-      "anyOf": [
-        {
-          "items": {
-            "description": "One row in the suburb directory — minimum to disambiguate SAL\nnames that collide across states (e.g. 'Springfield' in NSW + QLD).",
-            "example": {
-              "state": "New South Wales",
-              "suburb": "Belmont North"
-            },
-            "properties": {
-              "match": {
-                "anyOf": [
-                  {
-                    "type": "string"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "description": "How this row matched the `q` you sent — `exact`, `contains`, or `fuzzy` (a near-miss recovered from a likely typo). Only present when `q` was supplied. **Anything other than `exact` is a suggestion, not a confirmation: tell the user which suburb and state you used before you quote numbers for it.** A `fuzzy` row in a different state from the one the user named is very often the wrong place.",
-                "title": "Match"
-              },
-              "score": {
-                "anyOf": [
-                  {
-                    "type": "number"
-                  },
-                  {
-                    "type": "null"
-                  }
-                ],
-                "description": "Match confidence 0-1 (1.0 = exact). Only present when `q` was supplied. Use it to decide between asking the user and proceeding — not as a licence to pick silently.",
-                "title": "Score"
-              },
-              "state": {
-                "description": "State / Territory.",
-                "title": "State",
-                "type": "string"
-              },
-              "suburb": {
-                "description": "Suburb (SAL) name.",
-                "title": "Suburb",
-                "type": "string"
-              }
-            },
-            "required": [
-              "suburb",
-              "state"
-            ],
-            "title": "SuburbListItem",
-            "type": "object"
-          },
-          "type": "array"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "description": "The endpoint's payload, or `null` when Microburbs has no value.",
-      "title": "Data"
-    },
-    "message": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "description": "Human-readable explanation. Omitted on success.",
-      "title": "Message"
-    },
-    "reason": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "description": "Machine-readable slug naming the no-data condition (e.g. `no_avm_for_GANSW704074813`). Stable per endpoint. Omitted on success.",
-      "title": "Reason"
-    }
-  },
-  "title": "ApiResponse[list[SuburbListItem]]",
-  "type": "object",
-  "x-fastmcp-top-level-schema": "ApiResponse_list_SuburbListItem__"
-}New value: +null
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds substantial behavioral detail: the default 1000-row alphabetical limit, typo-tolerant fuzzy matching with match/score fields, the state-as-preference behavior when combined with q, and the instruction to always inform the user of resolution. It also notes 'Free.' No contradictions exist.

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?

The description is well-structured, front-loaded with the core behavior and return format, then progressively detailing filters, matching nuances, and user-facing guidance. Bold key terms highlight important points. Every sentence adds value; the length is justified by the tool's complexity.

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?

Given the tool's moderate complexity, the description covers all essentials: default behavior, filtering semantics, matching behavior, ambiguity handling, and cost. The schema fully documents parameters, and the annotations cover read-only/idempotent traits. No gaps remain for an agent to call this tool correctly.

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?

Although the schema already provides full parameter descriptions (100% coverage), the description adds crucial interaction semantics: filters combine with AND, state becomes a preference (not a strict filter) when used with q, and the default limit when no filter is passed. It also explains the fuzzy matching pipeline for q, which is more than the schema offers. This significantly enriches the schema's static definitions.

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 description opens with 'List Australian suburbs (SALs)' – a specific verb and resource. It immediately clarifies that rows include both suburb and state to disambiguate SAL-name collisions, distinguishing it from any other suburb-related tool. No ambiguity remains about what this tool does.

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?

The description gives clear usage context: no-filter returns a 1000-row preview, filters narrow results and combine with AND. It also instructs the agent to always disclose the resolved suburb and state, and to ask when ambiguous. However, it does not explicitly contrast this with sibling tools like suburbs_finder_search or suburbs_profile, so it stops short of full when-not-to-use guidance.

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