NSW development application data: search, nearby and detail tools. Paid per call via x402 (USDC).
Scored across 9 tools
The CDC and DA families are cleanly separated by a namespace prefix and each family has distinct get/summary/search/nearby verbs, so misselection is unlikely. The one wrinkle is nsw_da_resolve_address, which is a shared geocoding utility but is named only under the DA prefix, so an agent working with CDCs may not realize it applies to both.
Every tool follows the identical pattern nsw_<dataset>_<verb>_<object>: cdc/da prefixes with get_application, get_summary, search_applications, and search_nearby_applications reused verbatim across both datasets. The single deviation (resolve_address) still fits the convention.
Nine tools is well-scoped for a read-only public-data server: four operations replicated across two datasets plus one shared address resolver. No tool feels redundant or padded, and nothing obvious is missing from the count.
The surface covers the core lifecycle for both record types: summary discovery, keyword/date search, proximity search, and full-record retrieval, with free geocoding support. Gaps are minor for a read-only data API: no pagination beyond offset, no linked-document retrieval, and no coverage of related application categories (e.g. modifications or state-significant DAs).
Get the full record of one of the NSW complying development certificates (CDCs) by its Planning Portal CDC number. Returns every location with lot and plan, all development types, submission, lodgement, determination and exhibition dates, cost, dwellings, storeys, lots and the remaining source fields. Take CDC numbers from search_applications or search_nearby_applications. An unknown number returns not_found and is not charged. Costs $0.005 per call, paid via x402 in USDC on Base; clients without x402 support receive the payment requirements as an error result. Failed calls are not charged. Source: NSW Department of Planning, Housing and Infrastructure (NSW Planning Portal), CC BY 4.0.
| Name | Required | Description | Default |
|---|---|---|---|
| cdc | Yes | Planning Portal CDC number (e.g. CDC-388198) |
| Name | Required | Description |
|---|---|---|
| data | No | Result: a list of applications for search and nearby tools, one record or summary object otherwise |
| meta | Yes | Paging and query details, e.g. limit, offset, has_more, count |
| attribution | Yes | Source attribution; keep it when presenting the data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive hints. The description adds critical context beyond annotations: pricing ($0.005 per call via x402 on Base), that unknown numbers return 'not_found' and are not charged, that failed calls are not charged, and the fallback behavior for clients without x402 support. This is excellent disclosure of non-obvious operational traits.
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?
Front-loaded with purpose, then return contents, then sourcing guidance, then pricing/behavioral details. Every sentence earns its place with no redundancy. Well-structured and appropriately sized for the information density.
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?
Given the presence of an output schema (so return values need not be explained in detail), the description goes beyond by enumerating key fields returned, covering error cases, pricing, and data source attribution. Complete for a single-parameter getter with rich annotations.
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% and the parameter's schema description already provides the example format. The description restates that the parameter is 'Planning Portal CDC number' but adds no syntax or format details beyond what the schema provides. Baseline 3 is appropriate.
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?
States a specific verb ('Get the full record'), resource ('NSW complying development certificates'), and identifier ('Planning Portal CDC number'). Clearly distinguishes from sibling nsw_cdc_get_summary by emphasizing 'full record' and enumerating the fields returned.
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?
Explicitly tells the agent where to get valid CDC numbers ('Take CDC numbers from search_applications or search_nearby_applications'), which is the key precondition. Also specifies behavior for unknown numbers. No ambiguity about when to use this vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get free counts of NSW complying development certificates (CDCs) by status, application type and council. Call this first: it shows how many complying development certificates (CDCs) are loaded, the exact council names the other tools accept, and the status and application type values. Optional filters narrow the counts. Counts refresh every 6 hours while the history backfill extends coverage back to 2018. Free, no payment needed. Source: NSW Department of Planning, Housing and Infrastructure (NSW Planning Portal), CC BY 4.0.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Application status, exact match (e.g. Approved) | |
| council | No | Council name, partial case-insensitive match (see by_council in /summary) (e.g. Parramatta) | |
| application_type | No | Application type, exact match (e.g. Complying Development Certificate Application) |
| Name | Required | Description |
|---|---|---|
| data | No | Result: a list of applications for search and nearby tools, one record or summary object otherwise |
| meta | Yes | Paging and query details, e.g. limit, offset, has_more, count |
| attribution | Yes | Source attribution; keep it when presenting the data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, non-open-world behavior, so the bar is lower. The description adds genuinely useful operational context beyond that: a 6-hour refresh cadence, backfill coverage to 2018, no payment requirement, and a licensing/source attribution.
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?
Front-loaded and readable, but the opening sentence is a verbatim copy of the title, and 'Free, no payment needed' restates the 'free counts' phrase already used twice. The source/license sentence is the only part that could arguably be trimmed, but it is short.
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?
An output schema exists, so return-shape explanation is unnecessary. The description covers freshness, historical coverage, cost, and provenance, which is enough for a zero-required-parameter summary tool; only pagination/response-size expectations are absent.
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% and each parameter already documents its match semantics (exact vs partial case-insensitive) and examples. The description only says 'Optional filters narrow the counts', which adds no syntax or value detail beyond the schema, so the baseline 3 applies.
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 names a specific verb and resource ('Get free counts of NSW complying development certificates') and specifies the aggregation dimensions (status, application type, council). It is clearly separable from siblings like nsw_cdc_search_applications and nsw_da_get_summary by scoping to CDC counts.
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?
'Call this first' is an explicit workflow directive, and it explains why: it reveals loaded counts and the exact council/status/application-type values the other tools accept. It stops short of naming which specific sibling to use next or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search NSW complying development certificates (CDCs) by council, suburb, postcode or lodgement date, newest lodgement first. Returns up to 100 complying development certificates (CDCs) per call with address, status, cost, dwellings, storeys and development types, plus has_more for paging with offset. status, application_type, development_type and min_cost must be combined with council, suburb or postcode. Use get_application for the full record of a result. Costs $0.01 per call, paid via x402 in USDC on Base; clients without x402 support receive the payment requirements as an error result. Failed calls are not charged. Source: NSW Department of Planning, Housing and Infrastructure (NSW Planning Portal), CC BY 4.0.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1-100 (default 20) | |
| offset | No | Number of results to skip, 0-1000 (default 0) | |
| status | No | Application status, exact match (e.g. Approved) | |
| suburb | No | Suburb of the primary address, case-insensitive (e.g. ERMINGTON) | |
| council | No | Council name, partial case-insensitive match (see by_council in /summary) (e.g. Parramatta) | |
| min_cost | No | Minimum estimated cost of development in AUD (e.g. 1000000) | |
| postcode | No | 4-digit postcode of the primary address (e.g. 2115) | |
| lodged_to | No | Lodgement date upper bound, yyyy-mm-dd (e.g. 2026-06-30) | |
| lodged_from | No | Lodgement date lower bound, yyyy-mm-dd (e.g. 2026-01-01) | |
| application_type | No | Application type, exact match (e.g. Complying Development Certificate Application) | |
| development_type | No | Development type, partial match (e.g. dwelling) |
| Name | Required | Description |
|---|---|---|
| data | No | Result: a list of applications for search and nearby tools, one record or summary object otherwise |
| meta | Yes | Paging and query details, e.g. limit, offset, has_more, count |
| attribution | Yes | Source attribution; keep it when presenting the data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description goes well beyond them: 100-result cap per call, has_more/offset paging, $0.01 per-call cost paid via x402 in USDC on Base, the failure mode for non-x402 clients (payment requirements returned as an error result), and that failed calls are not charged. That is exactly the kind of cost, auth and error behavior annotations cannot express.
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?
Opens with purpose and scope, then results shape, then filter constraints, then routing, then billing, then provenance. Every sentence carries distinct operational information (paging, cost, payment fallback, licensing) with no filler or repetition of the title/schema.
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 an output schema present and full schema coverage, the description still usefully sketches the result fields and paging, plus billing, error behavior and data provenance. Nothing needed to decide whether and how to call this tool is missing.
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 per-parameter meanings are already documented and the baseline would be 3. The description adds a constraint not present in the schema — that four filter parameters are only valid in combination with a location parameter — which is genuine added semantic value.
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?
States a specific verb (Search) plus resource (NSW complying development certificates) with an explicit scope line (council, suburb, postcode, lodgement date) and ordering (newest lodgement first). It also names the sibling to use for the full record (get_application), so an agent can distinguish it from nsw_cdc_get_application and nsw_cdc_nearby_applications.
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?
Gives an explicit combining rule — status, application_type, development_type and min_cost must be paired with council, suburb or postcode — and routes to get_application for full records. It does not say when to prefer nsw_cdc_nearby_applications or nsw_cdc_summary over this tool, so one sibling choice is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find NSW complying development certificates (CDCs) within 2 km of a street address or latitude/longitude, nearest first. Pass address (e.g. '10 Brigalow Ave, Casula') and it is geocoded against the official NSW address register, or pass lat and lng. Returns the distance in metres for each result plus the same fields as search_applications; meta.geocode shows the matched address. An unknown or ambiguous address returns an error with suggestions and is not charged. lodged_from limits results to recent applications. Costs $0.02 per call, paid via x402 in USDC on Base; clients without x402 support receive the payment requirements as an error result. Failed calls are not charged. Source: NSW Department of Planning, Housing and Infrastructure (NSW Planning Portal), CC BY 4.0.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (WGS84); required unless address is given (e.g. -33.81) | |
| lng | No | Longitude (WGS84); required unless address is given (e.g. 151.06) | |
| limit | No | Max results, 1-100 (default 20) | |
| address | No | NSW street address with suburb; alternative to lat/lng (e.g. 10 Brigalow Ave, Casula NSW 2170) | |
| radius_m | No | Radius in metres, 1-2000 (default 500) | |
| lodged_from | No | Lodgement date lower bound, yyyy-mm-dd |
| Name | Required | Description |
|---|---|---|
| data | No | Result: a list of applications for search and nearby tools, one record or summary object otherwise |
| meta | Yes | Paging and query details, e.g. limit, offset, has_more, count |
| attribution | Yes | Source attribution; keep it when presenting the data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safe read-only, idempotent profile, and the description goes well beyond them: geocoding against the official NSW address register, meta.geocode in the response, unknown/ambiguous address errors with suggestions that are not charged, $0.02 per-call x402 USDC-on-Base payment with unpaid clients receiving payment requirements as an error, and no charge for failed calls. This is unusually rich behavioral disclosure.
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?
Front-loaded with the core action and scope, then packs input modes, return shape, error behavior, pricing, and provenance into a few dense sentences. Slightly long, but nearly every clause carries operational information an agent needs.
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?
An output schema exists, so return values need no elaboration, and the description still covers geocoding behavior, response meta, error semantics, cost/payment mechanics, and data source/licensing. Nothing an agent needs to call this correctly is missing.
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 coverage is already 100%, so the baseline is 3; the description still adds meaning by explaining that address is geocoded rather than matched literally, that lat/lng is the alternative, and that lodged_from restricts to recent applications. It does not clarify limit/radius_m semantics (radius_m default 500 vs the '2 km' phrasing) beyond what the schema states.
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?
States a specific verb and resource ('Find NSW complying development certificates (CDCs)') plus the scope (within 2 km, nearest first). This clearly separates it from nsw_cdc_search_applications and nsw_cdc_get_application without needing to open a schema.
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?
Explicitly gives the two input modes (address, which is geocoded, or lat/lng) and explains what lodged_from does. It references search_applications only for field parity rather than routing the agent away from this tool when a radius search is not wanted, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full record of one of the NSW development applications by its Planning Portal application number (PAN). Returns every location with lot and plan, all development types, submission, lodgement, determination and exhibition dates, cost, dwellings, storeys, lots and the remaining source fields. Take PAN numbers from search_applications or search_nearby_applications. An unknown number returns not_found and is not charged. Costs $0.005 per call, paid via x402 in USDC on Base; clients without x402 support receive the payment requirements as an error result. Failed calls are not charged. Source: NSW Department of Planning, Housing and Infrastructure (NSW Planning Portal), CC BY 4.0.
| Name | Required | Description | Default |
|---|---|---|---|
| pan | Yes | Planning Portal application number (PAN) (e.g. PAN-624302) |
| Name | Required | Description |
|---|---|---|
| data | No | Result: a list of applications for search and nearby tools, one record or summary object otherwise |
| meta | Yes | Paging and query details, e.g. limit, offset, has_more, count |
| attribution | Yes | Source attribution; keep it when presenting the data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description layers on genuinely non-derivable behavior: cost of $0.005 per call, x402/USDC-on-Base payment mechanics, the error result for clients lacking x402 support, no charge on failed or unknown-PAN calls, and the not_found return for unknown numbers. This is exactly the kind of context structured fields cannot carry.
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?
Front-loads purpose, then sourcing, then payment/failure semantics, then attribution — a sensible ordering with no filler. The long field enumeration is the only candidate for trimming, but it is bounded and directly supports the 'full record' claim.
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?
An output schema exists, so return-value detail is technically optional; the description still supplies it plus payment, failure, and provenance behavior. For a single-parameter tool, nothing an agent needs to invoke it correctly — input source, cost, and error semantics — is missing.
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 coverage is 100% and the single 'pan' property is self-documented with a format example (PAN-624302). The description adds provenance meaning beyond the schema by stating where valid PAN values originate (the search tools), which helps the agent construct a correct call rather than merely format it.
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?
States a specific verb and resource ('Get the full record of one of the NSW development applications') scoped by a named identifier (PAN). It explicitly distinguishes itself from the search siblings by naming them as the source of PANs and by describing the breadth of the returned record, so an agent can separate it from nsw_da_get_summary and nsw_da_search_applications without opening schemas.
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?
Gives a clear prerequisite chain: 'Take PAN numbers from search_applications or search_nearby_applications,' which tells the agent where valid input comes from. It does not explicitly state when to prefer this over nsw_da_get_summary or what to do if a PAN is not yet known beyond searching, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get free counts of NSW development applications by status, application type and council. Call this first: it shows how many development applications are loaded, the exact council names the other tools accept, and the status and application type values. Optional filters narrow the counts. Counts refresh every 6 hours while the history backfill extends coverage back to 2018. Free, no payment needed. Source: NSW Department of Planning, Housing and Infrastructure (NSW Planning Portal), CC BY 4.0.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Application status, exact match (e.g. Determined) | |
| council | No | Council name, partial case-insensitive match (see by_council in /summary) (e.g. Parramatta) | |
| application_type | No | Application type, exact match (e.g. Development Application) |
| Name | Required | Description |
|---|---|---|
| data | No | Result: a list of applications for search and nearby tools, one record or summary object otherwise |
| meta | Yes | Paging and query details, e.g. limit, offset, has_more, count |
| attribution | Yes | Source attribution; keep it when presenting the data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses traits beyond annotations: counts refresh every 6 hours, history backfill extends to 2018, it is free with no payment needed, and cites the data source and license. These are operational facts the agent would otherwise have to discover by trial.
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?
Front-loads the purpose and the 'Call this first' directive. Remaining sentences each add distinct facts (discovery role, refresh cadence, cost, source) with no 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?
Covers discovery value, filter behavior, data freshness, historical coverage, cost, and provenance – and an output schema exists, so return-value explanation is rightly omitted. Nothing an agent needs to call this correctly is missing.
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?
Type information is 'string or number' – the description notes filters are optional but does not resolve the ambiguity of accepting a number versus a name. The council hint pointing to by_council in /summary is a small, useful cross-reference beyond the schema. Baseline 3 is appropriate given the schema already documents the match semantics.
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?
States a specific verb (get), resource (NSW development applications), and dimensions (status, application type, council). Clearly distinguishes itself as a counts/aggregation tool rather than the search or get_application siblings.
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?
Explicitly says 'Call this first' and explains why: it reveals the loaded dataset size, exact council names, and status/application type values accepted by the other tools. This is precise routing guidance an agent can act on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a NSW street address to its official form and coordinates, free. Matches the address against the official NSW address register (Spatial Services). Use it to check an address before a paid nearby search, or to get latitude/longitude. Ambiguous input returns suggestions. Free, no payment needed. Source: NSW Department of Planning, Housing and Infrastructure (NSW Planning Portal), CC BY 4.0.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | NSW street address with suburb (e.g. 10 Brigalow Ave, Casula NSW 2170) |
| Name | Required | Description |
|---|---|---|
| data | No | Result: a list of applications for search and nearby tools, one record or summary object otherwise |
| meta | Yes | Paging and query details, e.g. limit, offset, has_more, count |
| attribution | Yes | Source attribution; keep it when presenting the data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, non-destructive, and closed-world, so the safety profile is settled. The description adds genuinely new behavior and cost context: ambiguous input returns suggestions, and the call is free/no payment, which matters given the paid nearby-search sibling. It does not describe rate limits or pagination, keeping it below 5.
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?
Front-loaded with the core purpose, then usage, then edge-case behavior and provenance. Mild redundancy: 'free' is asserted twice (opening sentence and 'Free, no payment needed'), and the first clause largely restates the title.
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 an output schema present, return values need no explanation, and the annotations cover the safety semantics. The description still supplies what structured fields cannot: the data source, license, cost model, and ambiguous-input behavior, leaving nothing an agent needs to call it correctly.
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% and the single 'address' parameter already carries an example format including suburb and postcode. The description adds no format, normalization, or partial-input syntax beyond what the schema provides, so this sits at the baseline.
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?
States a specific verb (resolve), resource (NSW street address), and output (official form and coordinates), and names the authoritative register it matches against (NSW address register / Spatial Services). An agent can immediately distinguish this from the DA search/get siblings, which deal with applications rather than addresses.
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?
'Use it to check an address before a paid nearby search, or to get latitude/longitude' gives clear selection context and points at the paid nearby-search alternative without naming it directly. Missing only an explicit pointer to the exact sibling tool name and a when-not-to-use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search NSW development applications by council, suburb, postcode or lodgement date, newest lodgement first. Returns up to 100 development applications per call with address, status, cost, dwellings, storeys and development types, plus has_more for paging with offset. status, application_type, development_type and min_cost must be combined with council, suburb or postcode. Use get_application for the full record of a result. Costs $0.01 per call, paid via x402 in USDC on Base; clients without x402 support receive the payment requirements as an error result. Failed calls are not charged. Source: NSW Department of Planning, Housing and Infrastructure (NSW Planning Portal), CC BY 4.0.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1-100 (default 20) | |
| offset | No | Number of results to skip, 0-1000 (default 0) | |
| status | No | Application status, exact match (e.g. Determined) | |
| suburb | No | Suburb of the primary address, case-insensitive (e.g. ERMINGTON) | |
| council | No | Council name, partial case-insensitive match (see by_council in /summary) (e.g. Parramatta) | |
| min_cost | No | Minimum estimated cost of development in AUD (e.g. 1000000) | |
| postcode | No | 4-digit postcode of the primary address (e.g. 2115) | |
| lodged_to | No | Lodgement date upper bound, yyyy-mm-dd (e.g. 2026-06-30) | |
| lodged_from | No | Lodgement date lower bound, yyyy-mm-dd (e.g. 2026-01-01) | |
| application_type | No | Application type, exact match (e.g. Development Application) | |
| development_type | No | Development type, partial match (e.g. dwelling) |
| Name | Required | Description |
|---|---|---|
| data | No | Result: a list of applications for search and nearby tools, one record or summary object otherwise |
| meta | Yes | Paging and query details, e.g. limit, offset, has_more, count |
| attribution | Yes | Source attribution; keep it when presenting the data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent/non-destructive annotations by disclosing the 100-result cap, has_more paging, the $0.01 x402 USDC-on-Base payment requirement, the error-result behavior for clients lacking x402, and that failed calls are not charged. These are material operational facts an agent cannot infer from structured fields.
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?
Front-loads purpose, then returns, then the filter constraint, then cost/payment, then provenance. Dense and information-bearing throughout, though the single block of prose runs long and could be broken into clearer segments.
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?
Covers purpose, filtering constraints, result shape, pagination, pricing and error behavior, plus source/licence attribution. Even though an output schema exists, the extra payment and combination rules leave nothing an agent needs to call this correctly.
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 coverage is 100%, so per-parameter formats are already documented and the baseline would be 3. The description adds genuine cross-parameter semantics, though: the dependency that status/application_type/development_type/min_cost are only valid when combined with a location filter, which the schema cannot express.
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?
States a specific verb and resource ('Search NSW development applications') with the filter axes (council, suburb, postcode, lodgement date) and the sort order. It also distinguishes itself from nsw_da_get_application by naming that sibling as the way to fetch a full record.
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?
Gives an explicit usage rule: 'status, application_type, development_type and min_cost must be combined with council, suburb or postcode.' It also routes the agent to get_application for full records, so both the constraint and the alternative are spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find NSW development applications within 2 km of a street address or latitude/longitude, nearest first. Pass address (e.g. '10 Brigalow Ave, Casula') and it is geocoded against the official NSW address register, or pass lat and lng. Returns the distance in metres for each result plus the same fields as search_applications; meta.geocode shows the matched address. An unknown or ambiguous address returns an error with suggestions and is not charged. lodged_from limits results to recent applications. Costs $0.02 per call, paid via x402 in USDC on Base; clients without x402 support receive the payment requirements as an error result. Failed calls are not charged. Source: NSW Department of Planning, Housing and Infrastructure (NSW Planning Portal), CC BY 4.0.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (WGS84); required unless address is given (e.g. -33.81) | |
| lng | No | Longitude (WGS84); required unless address is given (e.g. 151.06) | |
| limit | No | Max results, 1-100 (default 20) | |
| address | No | NSW street address with suburb; alternative to lat/lng (e.g. 10 Brigalow Ave, Casula NSW 2170) | |
| radius_m | No | Radius in metres, 1-2000 (default 500) | |
| lodged_from | No | Lodgement date lower bound, yyyy-mm-dd |
| Name | Required | Description |
|---|---|---|
| data | No | Result: a list of applications for search and nearby tools, one record or summary object otherwise |
| meta | Yes | Paging and query details, e.g. limit, offset, has_more, count |
| attribution | Yes | Source attribution; keep it when presenting the data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the read-only annotations: it discloses the geocoding step and its source register, the error-with-suggestions behaviour for unknown/ambiguous addresses, the billing model ($0.02, x402/USDC on Base), that failed or ungeocodable calls are not charged, and what a non-x402 client receives. These are exactly the operational facts an agent needs before calling.
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?
Front-loaded with purpose, then usage, then returns, then cost/source; each sentence carries distinct information. It is dense but not padded, though the payment and licensing sentences could be compressed slightly.
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 an output schema present the description need not spell out return fields, yet it still clarifies the two useful extras (per-result distance in metres, meta.geocode). Combined with the billing, error, and data-source notes, nothing material is missing for correct invocation.
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 schema already carries parameter definitions, giving a baseline of 3. The description adds real meaning on top: what the address string is matched against, the concrete example format, and what meta.geocode returns after matching.
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?
States a specific verb (Find), resource (NSW development applications), and scope (within 2 km of a street address or lat/lng, nearest first), which cleanly separates it from the radius-free sibling nsw_da_search_applications. An agent can tell what it does and how it orders results without opening the schema.
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?
Gives clear selection logic between the two input modes ('Pass address ... or pass lat and lng') and explains that lodged_from narrows to recent applications. It never explicitly says when to prefer this over nsw_da_search_applications or nsw_da_resolve_address, and lists no exclusions, so it stops short of a full when/when-not guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
nsw_cdc_get_summarynsw_cdc_nearby_applicationsnsw_cdc_search_nearby_applicationsnsw_cdc_summarynsw_da_get_summarynsw_da_nearby_applicationsnsw_da_resolve_addressnsw_da_search_nearby_applicationsnsw_da_summarynsw_cdc_get_applicationnsw_cdc_nearby_applicationsnsw_cdc_search_applicationsnsw_cdc_summarynsw_da_get_application1 field changedInput schema / properties / pan / descriptionPrevious value: -"Planning Portal application number (e.g. PAN-624302)"New value: +"Planning Portal application number (PAN) (e.g. PAN-624302)"nsw_da_get_application1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "attribution": {
+ "additionalProperties": false,
+ "description": "Source attribution; keep it when presenting the data",
+ "properties": {
+ "licence": {
+ "type": "string"
+ },
+ "licenceUrl": {
+ "type": "string"
+ },
+ "publisher": {
+ "type": "string"
+ },
+ "text": {
+ "description": "Attribution text to show alongside the data",
+ "type": "string"
+ }
+ },
+ "required": [
+ "publisher",
+ "licence",
+ "licenceUrl",
+ "text"
+ ],
+ "type": "object"
+ },
+ "data": {
+ "description": "Result: a list of applications for search and nearby tools, one record or summary object otherwise"
+ },
+ "meta": {
+ "additionalProperties": {},
+ "description": "Paging and query details, e.g. limit, offset, has_more, count",
+ "type": "object"
+ }
+ },
+ "required": [
+ "meta",
+ "attribution"
+ ],
+ "type": "object"
+}nsw_da_nearby_applications1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "attribution": {
+ "additionalProperties": false,
+ "description": "Source attribution; keep it when presenting the data",
+ "properties": {
+ "licence": {
+ "type": "string"
+ },
+ "licenceUrl": {
+ "type": "string"
+ },
+ "publisher": {
+ "type": "string"
+ },
+ "text": {
+ "description": "Attribution text to show alongside the data",
+ "type": "string"
+ }
+ },
+ "required": [
+ "publisher",
+ "licence",
+ "licenceUrl",
+ "text"
+ ],
+ "type": "object"
+ },
+ "data": {
+ "description": "Result: a list of applications for search and nearby tools, one record or summary object otherwise"
+ },
+ "meta": {
+ "additionalProperties": {},
+ "description": "Paging and query details, e.g. limit, offset, has_more, count",
+ "type": "object"
+ }
+ },
+ "required": [
+ "meta",
+ "attribution"
+ ],
+ "type": "object"
+}nsw_da_search_applications1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "attribution": {
+ "additionalProperties": false,
+ "description": "Source attribution; keep it when presenting the data",
+ "properties": {
+ "licence": {
+ "type": "string"
+ },
+ "licenceUrl": {
+ "type": "string"
+ },
+ "publisher": {
+ "type": "string"
+ },
+ "text": {
+ "description": "Attribution text to show alongside the data",
+ "type": "string"
+ }
+ },
+ "required": [
+ "publisher",
+ "licence",
+ "licenceUrl",
+ "text"
+ ],
+ "type": "object"
+ },
+ "data": {
+ "description": "Result: a list of applications for search and nearby tools, one record or summary object otherwise"
+ },
+ "meta": {
+ "additionalProperties": {},
+ "description": "Paging and query details, e.g. limit, offset, has_more, count",
+ "type": "object"
+ }
+ },
+ "required": [
+ "meta",
+ "attribution"
+ ],
+ "type": "object"
+}nsw_da_summary1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "attribution": {
+ "additionalProperties": false,
+ "description": "Source attribution; keep it when presenting the data",
+ "properties": {
+ "licence": {
+ "type": "string"
+ },
+ "licenceUrl": {
+ "type": "string"
+ },
+ "publisher": {
+ "type": "string"
+ },
+ "text": {
+ "description": "Attribution text to show alongside the data",
+ "type": "string"
+ }
+ },
+ "required": [
+ "publisher",
+ "licence",
+ "licenceUrl",
+ "text"
+ ],
+ "type": "object"
+ },
+ "data": {
+ "description": "Result: a list of applications for search and nearby tools, one record or summary object otherwise"
+ },
+ "meta": {
+ "additionalProperties": {},
+ "description": "Paging and query details, e.g. limit, offset, has_more, count",
+ "type": "object"
+ }
+ },
+ "required": [
+ "meta",
+ "attribution"
+ ],
+ "type": "object"
+}nsw_da_get_applicationnsw_da_nearby_applicationsnsw_da_search_applicationsnsw_da_summary111 web-data endpoints across 11 services. Pay per call in USDC via x402.
Pay-per-call web extract, DNS/WHOIS/IP lookup, PDF/RSS/sitemap tools. x402 USDC on Base/Algorand.
Search, URL-to-markdown, change detection, live data, x402 trust tools. USDC pay-per-call.
9 App Store endpoints. Pay per call in USDC via x402.
Add one secure layer between your agents and this server.