suburbs_development_construction_activitySatellite-detected construction change per mesh block plus a suburb rollup.
| 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": [
- {
- "additionalProperties": true,
- "description": "Satellite-detected construction activity per mesh block + rollup.",
- "example": {
- "area_level": "suburb",
- "area_name": "Belmont North",
- "mesh_blocks": [
- {
- "construction_score": 0.0849,
- "mb_code": "10436570000",
- "ndbi_2019": -0.148,
- "ndbi_2023": -0.1056,
- "ndbi_change": 0.0423,
- "ndvi_change": -0.0426
- }
- ],
- "summary": {
- "active_mb_count": 3,
- "avg_construction_score": -0.0456,
- "avg_ndbi_change": -0.02,
- "mb_count": 66
- }
- },
- "properties": {
- "area_level": {
- "description": "Always 'suburb'.",
- "title": "Area Level",
- "type": "string"
- },
- "area_name": {
- "description": "Suburb (SAL) name.",
- "title": "Area Name",
- "type": "string"
- },
- "mesh_blocks": {
- "description": "Per-mesh-block rows, highest score first.",
- "items": {
- "additionalProperties": true,
- "description": "Whether a mesh block looks like it has been built on lately, judged\nfrom satellite imagery.\n\nThe method: compare two satellite readings of the same ground, one from\n2019 and one from 2023. Hard surfaces (roofs, concrete, cleared pads)\nreflect light differently from vegetation, so more hard surface plus\nless greenery is the fingerprint of building work. Every number below is\na **dimensionless index, not a count of dwellings** — it tells you where\nsomething changed, never what or how many.\n\nTwo limits worth stating to any end user: the window is a single\n2019→2023 comparison, so this is a *presence* signal rather than a\ntimeline and it cannot date anything; and dry ground can read like bare\nconstruction ground, which is exactly why `construction_score` also\nrequires vegetation to have fallen.",
- "properties": {
- "construction_score": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "The headline 'has building happened here' indicator: how much the built-up index rose *net of* how much vegetation fell (`ndbi_change − ndvi_change`). A dimensionless signed index in roughly −1…+1, and in practice much nearer zero than that. Positive means hard surface gained while greenery was lost — the signature of construction; negative means the reverse. Rank mesh blocks by it rather than reading an absolute value, and remember it measures surface change, not dwellings built.",
- "title": "Construction Score"
- },
- "mb_code": {
- "description": "ABS mesh-block code for the small area these readings cover, as a digit string. Mesh blocks are the smallest ABS geography — roughly a block of 30–60 dwellings.",
- "title": "Mb Code",
- "type": "string"
- },
- "ndbi_2019": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "The 2019 baseline built-up reading (NDBI — Normalised Difference Built-up Index): a dimensionless ratio in −1…+1 where higher means more hard surface and lower means more vegetation or water. Given so you can see the starting point, e.g. a bare paddock vs an already dense block.",
- "title": "Ndbi 2019"
- },
- "ndbi_2023": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "The same built-up reading for 2023, on the identical −1…+1 scale. The difference against `ndbi_2019` is `ndbi_change`.",
- "title": "Ndbi 2023"
- },
- "ndbi_change": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "Change in built-up surface between 2019 and 2023 — `ndbi_2023 − ndbi_2019`, so positive means more hard surface (roofs, concrete, cleared ground) at the end of the window. Dimensionless, typically a small fraction. On its own it is confounded by dry conditions, since bare dry soil also reads as built-up; `construction_score` is the de-confounded version.",
- "title": "Ndbi Change"
- },
- "ndvi_change": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "Change in vegetation cover 2019→2023 (NDVI, the greenness counterpart to NDBI, also dimensionless). Negative means vegetation was lost — land cleared — which alongside a rising `ndbi_change` is the strongest sign of development. Positive means the area got greener.",
- "title": "Ndvi Change"
- }
- },
- "required": [
- "mb_code"
- ],
- "title": "ConstructionMb",
- "type": "object"
- },
- "title": "Mesh Blocks",
- "type": "array"
- },
- "summary": {
- "description": "Suburb rollup.",
- "properties": {
- "active_mb_count": {
- "description": "Mesh blocks with a positive construction score.",
- "title": "Active Mb Count",
- "type": "integer"
- },
- "avg_construction_score": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "Mean construction score across mesh blocks (signed composite index, ~-1 to +1; positive = net building activity).",
- "title": "Avg Construction Score"
- },
- "avg_ndbi_change": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "Mean NDBI change across mesh blocks.",
- "title": "Avg Ndbi Change"
- },
- "mb_count": {
- "description": "Mesh blocks with satellite coverage.",
- "title": "Mb Count",
- "type": "integer"
- }
- },
- "required": [
- "mb_count",
- "active_mb_count"
- ],
- "title": "ConstructionSummary",
- "type": "object"
- }
- },
- "required": [
- "area_name",
- "area_level",
- "summary",
- "mesh_blocks"
- ],
- "title": "SuburbConstructionActivity",
- "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[SuburbConstructionActivity]",
- "type": "object",
- "x-fastmcp-top-level-schema": "ApiResponse_SuburbConstructionActivity_"
-}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 that the data is satellite-detected and includes a suburb rollup, which is useful context, but it does not disclose operational traits like data freshness or limits.
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 10-word sentence that front-loads the key attributes ('satellite-detected construction change per mesh block') before adding the rollup. Every word earns its place with no redundancy.
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?
With no output schema, the description gives only a high-level output shape (mesh block detail plus suburb rollup). It leaves ambiguous what 'construction change' measures, the time period covered, and the exact fields in the rollup, which an agent may need to interpret results.
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%, so the description must compensate for the bare 'suburb_name' string parameter. It only implies the parameter selects the suburb for the rollup and does not specify accepted formats or examples, though the parameter name is self-explanatory.
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 specifies the resource ('construction change'), the detection method ('satellite-detected'), and the granularity ('per mesh block plus a suburb rollup'). This makes it distinguishable from sibling development tools that draw on council applications or zoning data, though it lacks an explicit verb like 'list' or 'get'.
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 the many sibling development tools such as suburbs_development_applications or suburbs_development_all. The description only states the output, leaving the agent to infer the use case.
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.