Suburb · Country-of-birth breakdown
suburbs_ethnicity_birthplaceCountry-of-birth breakdown from the ABS census.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| suburb_name | Yes |
suburbs_ethnicity_birthplaceCountry-of-birth breakdown from the ABS census.
| Name | Required | Description | Default |
|---|---|---|---|
| suburb_name | Yes |
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": [
- {
- "items": {
- "additionalProperties": true,
- "description": "One row of ancestry / birthplace data.",
- "example": {
- "ancestry": "Australians",
- "area_level": "suburb",
- "area_name": "Belmont North",
- "proportion": 0.926304347826087
- },
- "properties": {
- "ancestry": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Only on /ethnicity/ancestry.",
- "title": "Ancestry"
- },
- "area_level": {
- "description": "Always 'suburb'.",
- "title": "Area Level",
- "type": "string"
- },
- "area_name": {
- "description": "Suburb (SAL) name.",
- "title": "Area Name",
- "type": "string"
- },
- "birthplace": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Only on /ethnicity/birthplace.",
- "title": "Birthplace"
- },
- "proportion": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "Share of the suburb identifying with this category (0–1).",
- "title": "Proportion"
- }
- },
- "required": [
- "area_name",
- "area_level"
- ],
- "title": "EthnicityRow",
- "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[EthnicityRow]]",
- "type": "object",
- "x-fastmcp-top-level-schema": "ApiResponse_list_EthnicityRow__"
-}New value: +nullDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the data source ('ABS census'), which is a small contextual addition. However, it says nothing about return format, pagination, or other behavioral characteristics, though the annotation coverage lowers the burden.
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 a single, front-loaded sentence with no filler. It conveys its core message efficiently and earns its place. There is no wasted wording or structural padding.
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?
For a tool with no output schema and minimal parameter docs, the description is too vague. 'Breakdown' is ambiguous (counts? percentages? raw numbers?). It also does not mention what inputs are needed or how results relate to the suburb_name parameter. An agent would not be fully equipped to interpret the output or confidently differentiate this from related ethnicity tools.
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 0%, and the description makes no mention of the suburb_name parameter or how to specify it. The parameter name is self-explanatory, but the description fails to compensate for the missing schema documentation. Per the low-coverage rule, the description must carry this burden, and it does not.
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 clearly identifies the resource as a country-of-birth breakdown from the ABS census, which distinguishes it from sibling tools like suburbs_ethnicity_ancestry or suburbs_demographics_*. However, it uses a noun phrase rather than a verb like 'get' or 'list', so it lacks an explicit action. The resource is specific enough for an agent to infer the tool's purpose.
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?
No guidance is given on when to use this tool versus alternatives. With many closely-related siblings (e.g., suburbs_ethnicity_all, suburbs_demographics_*), the description does not state a selection criterion or exclusion. The tool is effectively isolated with no usage context.
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.