Skip to main content
Glama

Find NSW development applications within 2 km of a street address or latitude/longitude, nearest first.

nsw_da_search_nearby_applications
Read-onlyIdempotent

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; the first 3 paid-tool calls per day are free for MCP clients while a shared daily allowance lasts. Without x402 support, later calls return 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.

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_search_nearby_applications"
  }
}

Input Schema

NameRequiredDescriptionDefault
latNoLatitude (WGS84); required unless address is given (e.g. -33.81)
lngNoLongitude (WGS84); required unless address is given (e.g. 151.06)
limitNoMax results, 1-100 (default 20)
addressNoNSW street address with suburb; alternative to lat/lng (e.g. 10 Brigalow Ave, Casula NSW 2170)
radius_mNoRadius in metres, 1-2000 (default 500)
lodged_fromNoLodgement date lower bound, yyyy-mm-dd

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. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond annotations (readOnly, idempotent, non-destructive), the description discloses geocoding behavior, error handling for unknown/ambiguous addresses with suggestions, charging rules ($0.02, first 3 free, failed calls not charged), x402 payment mechanics, and source/licensing. 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.

Conciseness4/5

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

The description is front-loaded with purpose and usage, then payment/error details. It is somewhat long, and the failure-charging point appears twice in different words, but nearly every sentence carries operational value.

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?

Despite complexity (6 optional parameters, geocoding, payment model, possible errors), the description covers how to call it, what happens on ambiguous input, cost and free-tier mechanics, and what the output includes. An output schema exists, so return fields need not be exhaustively described.

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 the baseline is 3. The description adds value by explaining that address is geocoded against the official NSW address register, that lat/lng is an alternative, and that lodged_from acts as a recency lower bound.

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

Purpose5/5

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

The description states a specific verb and resource ('Find NSW development applications'), precise geographic scope ('within 2 km'), and ordering ('nearest first'). It is distinguishable from the sibling 'search_applications' text search because proximity and distance are explicit.

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

Usage Guidelines4/5

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

It clearly says to pass either an address (geocoded) or lat/lng, and explains that lodged_from limits to recent applications. It doesn't explicitly say when to prefer this over nsw_da_search_applications or when to use nsw_da_resolve_address separately, but the proximity-search context is clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources