Skip to main content
Glama
Sign In

NSW Planning Data (x402)

by io.github.zuo305
OverviewDiscussionsAdmin

Get counts of NSW development applications by status, application type and council.

nsw_da_get_summary
Read-onlyIdempotent

Get counts of NSW development applications by status, application type and council. Call it before nsw_da_search_applications or nsw_da_search_nearby_applications: it returns the total loaded and by_status, by_application_type and by_council lists of { key, count }, whose keys are the exact filter values those tools accept. Filters are optional and combine with AND; without them the counts cover all of NSW. Counts refresh every 6 hours while the history backfill extends coverage back to 2021. Free, no payment needed. Source: NSW Department of Planning, Housing and Infrastructure (NSW Planning Portal), CC BY 4.0.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "nsw_da_get_summary"
  }
}

Input Schema

NameRequiredDescriptionDefault
statusNoApplication status, exact and case-sensitive; valid values are the keys of by_status in nsw_da_get_summary (e.g. Determined)
councilNoCouncil name or part of it, case-insensitive; matches every council whose name contains it. Full names are in by_council of nsw_da_get_summary (e.g. Parramatta)
application_typeNoApplication type, exact and case-sensitive; valid values are the keys of by_application_type in nsw_da_get_summary (e.g. Development Application)

Output Schema

NameRequiredDescriptionDefault
dataNoResult: a list of applications for search and nearby tools, one record or summary object otherwise
metaYesPaging and query details, e.g. limit, offset, has_more, count
attributionYesSource attribution; keep it when presenting the data

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / application_type / description
      Previous value: -"Application type, exact match (e.g. Development Application)"New value: +"Application type, exact and case-sensitive; valid values are the keys of by_application_type in nsw_da_get_summary (e.g. Development Application)"
    • changedInput schema / properties / council / description
      Previous value: -"Council name, partial case-insensitive match (see by_council in /summary) (e.g. Parramatta)"New value: +"Council name or part of it, case-insensitive; matches every council whose name contains it. Full names are in by_council of nsw_da_get_summary (e.g. Parramatta)"
    • changedInput schema / properties / status / description
      Previous value: -"Application status, exact match (e.g. Determined)"New value: +"Application status, exact and case-sensitive; valid values are the keys of by_status in nsw_da_get_summary (e.g. Determined)"
  2. Added

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds substantive traits beyond them: a 6-hour refresh cadence (staleness), backfill coverage extending to 2021 (data horizon), no payment required, and named source with license. These are exactly the operational facts an agent needs to reason about result freshness and completeness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then usage/ordering, then behavioral caveats, then provenance. Every sentence carries distinct information — even the short refresh and backfill clauses encode constraints — with no restatement of the title or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description still names the return shape (total plus by_status, by_application_type, by_council of { key, count }), which is precisely the information needed to use the result as a filter source for sibling calls. With annotations covering safety and provenance covered too, nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description earns extra by closing the loop across tools — the { key, count } lists produced here are the canonical filter values, and status/application_type are exact-match while council is a case-insensitive substring match. That cross-tool coupling is real meaning beyond the schema text, though the per-parameter mechanics largely duplicate what the schema already says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource plus the three breakdown dimensions (status, application type, council), which cleanly separates it from the search siblings that return records rather than counts. It does not, however, differentiate itself from nsw_cdc_get_summary, which by naming convention appears to be the equivalent counts tool for a different scheme, leaving one plausible sibling ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly prescribes ordering: call this before nsw_da_search_applications or nsw_da_search_nearby_applications, and explains why — the returned keys are the exact filter values those tools accept. It also states that filters are optional, combine with AND, and default to all of NSW, so the agent knows both when to use it and how to call it with or without filters.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All NSW Planning Data (x402) toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources