Quarterly building activity (8752.0) — value of work done and commenced at LGA level. Complements building approvals.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | AU state code: NSW, VIC, QLD, SA, WA, TAS, NT, ACT | |
| suburb | Yes | Suburb name, e.g. "Parramatta" | |
| postcode | No | 4-digit postcode, narrows disambiguation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It usefully conveys that the data is quarterly, covers value of work done and commenced, and is aggregated at LGA level. It does not disclose read-only nature, parameter behavior, default scoping, or return format, so it provides only partial transparency.
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 sentence that packs the essential facts: data source, cadence, measures, and geography. Every clause adds value, and the sibling relationship is stated without excess verbiage.
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 description covers the data source, metric, frequency, and geographic level, which is reasonably complete for a data-retrieval tool. However, with no output schema and three parameters that affect geographic disambiguation, it does not explain how the query parameters map to results or what the returned time series looks like.
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?
The input schema documents all three parameters — state, suburb, and postcode — with 100% coverage, so the baseline is 3. The description's mention of 'LGA level' hints at the geographic filtering role of these parameters but adds no concrete detail about how suburb, state, or postcode are combined or disambiguated.
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 identifies a specific resource — quarterly building activity from ABS catalog 8752.0 — and clarifies the key measures (value of work done and commenced) and geography (LGA level). It also distinguishes the tool from the sibling au-abs-building-approvals by noting it complements rather than duplicates that data. However, it lacks an explicit verb such as 'returns' or 'retrieves', so it falls just short of a 5.
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 phrase 'Complements building approvals' gives useful context that this tool covers building activity rather than approvals, and implies these two tools can be used together. It does not explicitly state when to choose this tool over alternatives or when it should not be used, so the usage guidance remains implied rather than fully specified.
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.
Every tool maps to a clearly distinct dataset or lookup, with country prefixes and topic names separating overlapping domains. Even similar tools like au-abs-building-activity and au-abs-building-approvals are unambiguously differentiated by their descriptions.
The data tools follow a consistent country/topic hyphenated pattern (au-*, nz-*), making resource selection predictable. The meta tools (get_catalog, list_services, health) break this pattern with imperative/underscore names, but this is a minor and understandable deviation.
At 26 tools, the set is on the heavy side and slightly exceeds the typical comfortable range. However, each tool represents a genuinely distinct data service, and the clear grouping by country and topic keeps the surface navigable.
The server covers a broad range of common agent data needs for Australia and New Zealand: demographics, income, building, labour, weather, time, holidays, school terms, and place resolution. Minor gaps exist, such as no NZ building data or broader international coverage, but core workflows are well supported.