Skip to main content
Glama

Microburbs Australian Property Data

suburbs_list

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.

Price: 3¢ per call.

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).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoThe endpoint's payload, or `null` when Microburbs has no value.
reasonNoMachine-readable slug naming the no-data condition (e.g. `no_avm_for_GANSW704074813`). Stable per endpoint. Omitted on success.
messageNoHuman-readable explanation. Omitted on success.
availableNo`false` on no-data responses. Omitted on success — branch on `data !== null` if you want a single discriminator.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and handles it exceptionally well. It discloses the default 1000-row alphabetical preview, AND filter semantics, typo-tolerant q behavior with match/score fields, the state-as-preference behavior, and the 3¢ per call pricing. It also adds valuable guidance about confirming resolved suburbs, going far beyond basic expectations.

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 longer than average but every section earns its place: default behavior, filter semantics, fuzzy-match behavior, user-communication guidance, state preference nuance, and cost. It is front-loaded with the core purpose and return shape, then builds into edge-case behavior without redundancy.

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?

For a list tool with an output schema, this description covers everything needed to call it correctly: default pagination behavior, all filter semantics, fuzzy-match disambiguation, state-preference behavior, and cost. The agent can understand both the tool mechanics and how to handle ambiguous suburb names responsibly.

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

Parameters4/5

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

Schema description coverage is 100%, so the schema already documents each parameter; baseline is 3. The description adds meaningful semantics beyond the schema: filters combine as AND, q is typo-tolerant and returns match/score, and state acts as a preference rather than a strict filter when combined with q. This justifies a score above baseline but not the maximum.

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 opens with a specific verb and resource: 'List Australian suburbs (SALs)', and clarifies that rows always contain {suburb, state} to resolve name collisions. This clearly identifies the tool's scope, but it does not explicitly distinguish it from the similar-looking suburbs_finder_search sibling, so it stops short of full sibling differentiation.

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 concrete when-to-use context: no filter returns the first 1000 suburbs alphabetically, while passing state/lga/sa4/sa3/postcode/q narrows results, with filters combining as AND. It stops short of naming alternatives or stating when not to use this tool, so it lacks an explicit exclusion clause.

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