area_stats_regionsList the regions that exist at a level — every suburb, LGA, postcode, etc. Free (0c). Use it to discover the exact region names to pass to /values.
Free.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max regions to return. | |
| query | No | Filter by region name (substring, case-insensitive). Omit to list. | |
| region_level | Yes | Region level: SAL (suburb), SA1, SA2, SA3, SA4, LGA, POA, GCCSA, STE, AUS. |
Changes observed during successful MCP inspections.
Output 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": [
- {
- "description": "The regions available at one level.",
- "example": {
- "count": 1,
- "region_level": "LGA",
- "regions": [
- {
- "region_code": "14750",
- "region_name": "Lake Macquarie"
- }
- ]
- },
- "properties": {
- "count": {
- "description": "Number of regions returned.",
- "title": "Count",
- "type": "integer"
- },
- "region_level": {
- "description": "Region level (SAL, SA1-4, LGA, POA, GCCSA, STE, AUS).",
- "title": "Region Level",
- "type": "string"
- },
- "regions": {
- "description": "Regions, name-sorted.",
- "items": {
- "description": "One region at a given level.",
- "properties": {
- "region_code": {
- "description": "Region code.",
- "title": "Region Code",
- "type": "string"
- },
- "region_name": {
- "description": "Region name (the SA1 code for SA1 — SA1s are unnamed).",
- "title": "Region Name",
- "type": "string"
- }
- },
- "required": [
- "region_code",
- "region_name"
- ],
- "title": "AreaStatRegion",
- "type": "object"
- },
- "title": "Regions",
- "type": "array"
- }
- },
- "required": [
- "region_level",
- "count",
- "regions"
- ],
- "title": "AreaStatRegionsResponse",
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "description": "The endpoint's payload, or `null` when Microburbs has no value."
- },
- "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[AreaStatRegionsResponse]",
- "type": "object",
- "x-fastmcp-top-level-schema": "ApiResponse_AreaStatRegionsResponse_"
-}New value: +nullDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful extras: the cost signal 'Free (0c)' and the completeness claim 'every suburb, LGA, postcode, etc.' There is no contradiction, and the description does not overstate behavior beyond what a list endpoint would do.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the core action, and includes the valuable /values routing. However, 'Free (0c)' and '**Free.**' are redundant, repeating the same cost information twice. The duplication keeps it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The combination of the description and fully-covered schema gives an agent enough to call the tool correctly. Minor gaps exist around the exact output shape and default-limit behavior, but the schema already documents limits and defaults, and the purpose is simple enough that these are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies. The description adds only the contextual hint that returned names feed into /values, but it does not explain individual parameters beyond what the schema already provides. This is acceptable because region_level, limit, and query are each well-described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'List' and a clear resource: regions that exist at a level, with concrete examples ('every suburb, LGA, postcode'). It is immediately distinguishable from sibling tools like area_stats_fields because the target object, regions, is explicit. The title reinforces the same purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly routes the agent to use this tool to discover exact region names to pass to /values, which establishes a clear before-values workflow. It does not enumerate exclusions against other list tools like suburbs_list or lga_list, but within the area_stats family the routing is concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.