properties_development_zoning_codePrimary zoning at the property's point — code (R2, B4, ...) when the council ships one, plus the human-readable name and the broader category.
Price: 3¢ per call.
| Name | Required | Description | Default |
|---|---|---|---|
| gnaf_id | 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": [
- {
- "example": {
- "category": "Residential Zones",
- "code": "R2",
- "name": "Low Density Residential"
- },
- "properties": {
- "category": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Broader category bucket, e.g. 'Residential Zones', 'Business Zones'.",
- "title": "Category"
- },
- "code": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Parenthesised code (e.g. 'R2', 'B4', 'IN1') when the council's feed includes one. Many regional NSW + Adelaide + QLD councils don't — in which case this is null and the human-readable label is on `name`.",
- "title": "Code"
- },
- "name": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Human-readable zone class, e.g. 'Low Density Residential'.",
- "title": "Name"
- }
- },
- "title": "ZoningCode",
- "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[ZoningCode]",
- "type": "object",
- "x-fastmcp-top-level-schema": "ApiResponse_ZoningCode_"
-}New value: +nullDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety behavior. The description adds useful context by noting the code is returned only 'when the council ships one,' implying possible absence, and enumerates the returned fields. However, it does not describe what happens when the council does not provide a code, or any rate-limit/auth behavior.
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 definition is two sparse sentences: it states the output, the caveat, and the price with no filler. Every sentence earns its place and the most important identifying information is front-loaded.
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 one-parameter, read-only, idempotent tool, the description covers the primary output, the conditional absence, and the price. Still, it omits any explanation of gnaf_id and the empty/missing-data behavior, so an agent must infer identifier semantics from the name alone.
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 undocumented gnaf_id parameter. It only says 'at the property's point' and never explains what a GNAF ID is, its expected format, or how to obtain it. The bare parameter name leaves too much to inference.
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 tool's output: the primary zoning code at the property's point, along with the human-readable name and the broader category. It distinguishes from overlay-focused siblings through the word 'primary' and the listed return fields, but it has no explicit verb and does not name a sibling.
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 over properties_development_zoning_overlays or properties_development_all. The 'primary' wording implies this is the base zoning result, but there are no explicit when-to-use or when-not-to-use instructions, nor any prerequisites for obtaining gnaf_id.
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.