NSW development application data: search, nearby and detail tools. Paid per call via x402 (USDC).
Scored across 8 tools
The prefix scheme (nsw_cdc_ vs nsw_da_) cleanly separates the two data families, and within each family get/search/nearby/summary are distinct actions. There is mild overlap in that nsw_da_nearby and nsw_cdc_nearby both answer 'what is being built near here', so an agent must know the CDC vs DA distinction to pick correctly, but descriptions make the boundary clear.
Every tool follows a strict prefix + verb_noun pattern (nsw_{cdc|da}_{get_application|search_applications|nearby_applications|summary}), with the two families perfectly parallel. The only minor deviation is 'summary' as a noun rather than a verb, but it is used identically in both families, so the pattern stays predictable.
Eight tools form two tidy, symmetric families of four, each earning its place (search, get, nearby, summary). This is well-scoped for a read-only spatial/records API with no redundancy.
The surface covers the full read lifecycle for both CDC and DA records: summary for discovery, search with paging, single-record get, and geo-proximity lookup. Minor gaps exist (no bulk export or explicit development-type reference listing beyond what summary exposes), but core workflows have no dead ends.
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 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 cover readOnly/idempotent/non-destructive, but the description goes well beyond them: unknown numbers return not_found without charge, the call costs $0.005 via x402 USDC on Base, non-x402 clients get payment requirements as an error, and failed calls are not charged. This is exactly the operational context an agent needs before invoking a paid lookup.
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?
Purpose is front-loaded and every following sentence adds concrete value (returned fields, input source, error behavior, pricing, licensing). It is dense and slightly long for a one-parameter tool, but there is little padding to cut.
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 needn't explain return values, and it still summarizes them; combined with annotations and full param coverage, an agent has everything needed to select and call the tool correctly, including payment and failure handling.
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 param is documented with an example ('CDC-388198'), so the schema already carries the semantics. The description names the key conceptually but adds no format or validation 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?
States a specific verb and resource ('Get the full record of one of the NSW complying development certificates') with the exact lookup key ('Planning Portal CDC number'). It also enumerates the returned fields, letting an agent distinguish it from the search/nearby/summary siblings 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?
Explicitly routes the agent to the correct input source: 'Take CDC numbers from search_applications or nearby_applications.' This is clear usage context, but it stops short of stating when NOT to use it (e.g. use nsw_cdc_summary for aggregate figures rather than per-record fetches).
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 latitude/longitude, nearest first. Returns the distance in metres for each result plus the same fields as search_applications. Use it to answer what is being built or proposed near an address: geocode the address first, then pass its coordinates. 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 | Yes | Latitude (WGS84) (e.g. -33.81) | |
| lng | Yes | Longitude (WGS84) (e.g. 151.06) | |
| limit | No | Max results, 1-100 (default 20) | |
| 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 declare the safe read-only/idempotent profile, and the description goes well beyond them: cost of $0.02 per call, x402 payment in USDC on Base, the exact failure mode for clients without x402 (payment requirements returned as an error result), and the no-charge-on-failure policy. Data provenance and licence (NSW Planning Portal, CC BY 4.0) are also disclosed.
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 and scope, then usage workflow, then the one semantic parameter note, then billing and provenance. Every sentence is doing work, though the licensing/source sentence is the least load-bearing part for tool selection.
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 correctly delegated ('same fields as search_applications' plus distance in metres). For a paid, spatially-scoped, read-only lookup, the description covers invocation workflow, cost, failure semantics and data source — nothing an agent needs to call it 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 description coverage is 100%, so the baseline is 3, and the description earns a bump by explaining what lodged_from actually does ('limits results to recent applications') and by noting the response includes a distance in metres. It does not restate lat/lng/limit/radius_m, which the schema already covers.
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'), a precise resource (NSW complying development certificates / CDCs), a spatial scope (within 2 km of a lat/lng) and an ordering guarantee (nearest first). This cleanly separates it from nsw_cdc_search_applications and from the DA-variant sibling nsw_da_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 a concrete usage recipe: 'Use it to answer what is being built or proposed near an address: geocode the address first, then pass its coordinates.' It also points at search_applications for the returned field set, implying the sibling relationship. It stops short of an explicit 'do not use this when...' exclusion, but the context is unambiguous.
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.
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 cover read-only/idempotent/non-destructive, but the description adds genuinely useful operational context: counts refresh every 6 hours and the history backfill extends coverage back to 2018. It also confirms the tool is free and names the data source and license, though it says nothing about failure modes or rate 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 key guidance ('Call this first' and what it unlocks) is front-loaded right after the purpose sentence, and each sentence carries information. The trailing source/license sentence is slightly administrative but justifies its place as provenance for a public dataset.
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-value explanation is unnecessary, and the description covers the remaining gaps: freshness cadence, historical coverage window, cost, and the tool's role as a value-discovery step before the sibling query 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 100%, so the three filters and their matching semantics (exact vs partial case-insensitive) are already documented in the schema. The description only adds that filters are optional and narrow the counts, which is marginal value over the structured fields.
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 (counts of NSW complying development certificates) and states the three aggregation dimensions (status, application type, council), which cleanly separates it from the sibling search/get/nearby tools.
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?
It explicitly instructs 'Call this first' and explains why: it reveals how many CDCs are loaded, the exact council names the other tools accept, and valid status/application_type values. It also notes filters are optional and only narrow the counts, so the agent knows both when to call it and how to call it.
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 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?
Goes well beyond the annotations (readOnly, idempotent, non-destructive) by disclosing pricing ($0.005/call via x402 in USDC on Base), what happens without x402 support, that failed calls are not charged, and that an unknown PAN returns not_found without charge. This is exactly the kind of operational context an agent needs before invoking a paid tool.
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?
Purpose and the return scope are front-loaded, and the payment/error caveats are compact. The source and license sentence is slightly boilerplate but still earns its place as provenance for a data tool.
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 single-parameter lookup with an output schema, the description covers everything the agent needs: where the PAN comes from, what the record contains, billing, and failure behavior. Return-value detail is unnecessary given the output schema, which the description appropriately summarizes rather than restates.
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% with an example (PAN-624302), so the baseline is 3, but the description adds sourcing semantics beyond the schema by specifying that PAN values should come from search_applications or nearby_applications.
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 precise verb+resource ('Get the full record') plus the keying identifier (PAN), and distinguishes itself from the search/nearby siblings by indicating this returns the full record for one application. An agent can tell it apart from nsw_da_search_applications without opening either 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 routes the agent on where the PAN comes from ('Take PAN numbers from search_applications or nearby_applications'), which establishes the correct call ordering. It does not state exclusions or when not to use it, but the sequencing guidance is clear and actionable.
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 latitude/longitude, nearest first. Returns the distance in metres for each result plus the same fields as search_applications. Use it to answer what is being built or proposed near an address: geocode the address first, then pass its coordinates. 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 | Yes | Latitude (WGS84) (e.g. -33.81) | |
| lng | Yes | Longitude (WGS84) (e.g. 151.06) | |
| limit | No | Max results, 1-100 (default 20) | |
| 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 declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the $0.02 per-call cost, x402 USDC-on-Base payment mechanism, that failed calls are not charged, and that non-x402 clients get payment requirements back as an error. It also discloses the return shape (distance in metres plus search_applications fields) and the data source/licence.
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 workflow, then cost. Every sentence carries information, though the x402/payment sentence is long and could be tightened without losing meaning.
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?
Output schema exists so return values need not be enumerated, and the description still usefully references field parity with search_applications. Coverage of workflow, cost, and failure semantics is strong; the gaps are the unexplained radius_m/limit controls and the unresolved tension between the hard-coded '2 km' phrasing and the tunable radius parameter.
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 baseline is 3, but the description adds meaning for lodged_from ('limits results to recent applications') and establishes the geocode-then-pass-coordinates pattern for lat/lng. It does not mention radius_m or limit, and its fixed 'within 2 km' framing sits awkwardly beside a radius_m default of 500 m and max of 2000 m.
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 a precise spatial scope (within 2 km of a lat/lng, nearest first). An agent can distinguish this from nsw_da_search_applications (text-based search) and nsw_cdc_nearby_applications (different dataset) without opening 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?
Gives an explicit workflow for the primary use case: 'geocode the address first, then pass its coordinates.' It also notes lodged_from is for recent-only results. However, it never states when to prefer this over nsw_da_search_applications or nsw_cdc_nearby_applications, so sibling routing 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.
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.
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?
Annotations already declare readOnly, idempotent, non-destructive, non-open-world, so the safety profile is covered. The description goes beyond them by disclosing data freshness (counts refresh every 6 hours), coverage depth (history backfill to 2018), zero cost, and the authoritative source plus license—all genuinely useful for judging result trustworthiness.
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 content is front-loaded with the core operation and the 'call this first' directive, and every sentence carries information. There is minor redundancy—'free' appears in the opening sentence and again as 'Free, no payment needed'—and the title duplicates the first sentence, slightly diluting conciseness.
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 only 3 optional parameters, full schema coverage, and an output schema handling the return shape, the description supplies everything else needed: when to call it, data freshness, temporal coverage, cost, and provenance. Nothing an agent requires to invoke it 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 description coverage is 100%, and each parameter already documents its matching rule (exact match for status/application_type, partial case-insensitive for council). The description only says 'Optional filters narrow the counts,' adding no syntax or matching nuance 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 states a specific verb and resource—'Get free counts of NSW development applications'—and names the exact dimensions counted (status, application type, council). This clearly separates it from the sibling search/get/nearby tools, which operate on individual records rather than aggregates.
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' gives explicit sequencing guidance, and the reason is spelled out: it reveals how many applications are loaded, the exact council names the other tools accept, and the valid status and application type values. An agent knows to invoke this as a discovery step before the other tools without any inference.
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_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.