Skip to main content
Glama

DataQuoll

by io.dataquoll

Disaster declaration status for an exact point

declarations_by_point
Read-only

Returns the declaration STATUS for the local government area containing a lat/lng point, resolved against ABS LGA 2022 (ASGS Edition 3) boundary polygons at full resolution. POST with a JSON body is used deliberately so coordinates never appear in URLs or request logs; the request is read-only and safe to retry. Coordinates are never stored, logged, or echoed back, and the response is Cache-Control: no-store. Reports declared-area status only; the billing decision rests with the practitioner. A point outside every Australian LGA returns unknown_location. A point exactly on a shared LGA boundary returns every covering area with onBoundary=true. LGA matching is at ABS code level; some ABS codes aggregate multiple administrative areas (for example Unincorporated NSW covers both Far West and Lord Howe Island).

Requires the "declarations" entitlement on the API key. Accounts without it get a clear error rather than an empty result, so an empty response never means "not entitled".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latYes
lngYes
as_atNoPoint-in-time check (YYYY-MM-DD). Defaults to today.
include_expiredNoInclude expired records in the per-LGA lists. Never changes matchStatus.
instrument_typeNoTrim the returned record lists to one instrument type. Never changes matchStatus.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses that the request is safe to retry, coordinates are never stored/logged/echoed, responses use Cache-Control: no-store, and missing entitlements produce a clear error rather than an empty result. This is substantial behavioral context that annotations alone do not provide.

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?

The description is front-loaded with the core purpose, then efficiently covers method rationale, privacy behavior, return edge cases, boundary resolution quirks, and entitlement requirements. Every sentence adds distinct information; none are redundant filler.

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

Completeness4/5

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

Given there is no output schema, the description does a strong job of explaining key return behavior: unknown_location for outside points, onBoundary=true for shared boundaries, and per-LGA lists. It does not enumerate every possible status value or the full response envelope, so a bit of return-value detail remains unspecified, keeping this just below a 5.

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 60%; lat and lng have no schema descriptions, and the description adds meaning to them by explaining that they are resolved against ABS LGA 2022 full-resolution boundaries and by covering outside/boundary edge cases. The optional parameters as_at, include_expired, and instrument_type are already described in the schema, so the description does not need to repeat them.

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 opens with a specific verb and resource: it returns declaration STATUS for the local government area containing a lat/lng point. The 'exact point' framing and LGA-boundary resolution clearly separate it from siblings like declarations_by_postcode and declaration_by_agrn, even though those alternatives are not named.

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?

The description gives clear context for when this tool applies: you have an exact lat/lng point and need declared-area status only. It also explains boundary cases and scope, but it does not explicitly say 'use declarations_by_postcode instead for a postcode' or provide an exclusion list, so it stops short of a 5.

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

All DataQuoll toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools target a distinct resource and action, and the descriptions are detailed enough to separate declaration lookups, hazard history, incidents, events, and gauges. A couple of pairs could still be confused at first glance, such as declarations_by_point vs hazard_history_by_point or list_events vs list_incidents, but the descriptions resolve the boundaries.

Naming Consistency4/5

The naming largely follows a clear get_/list_ convention for single resources versus collections, with lookup-style names like declarations_by_point and declarations_by_postcode. Minor deviations such as incident_snapshot, nearby_incidents, and the singular declaration_by_agrn prevent a perfect score.

Tool Count4/5

19 tools is on the heavier side, but the count is justified by the broad domain covering current incidents, historical incidents, clustered events, declarations, river gauges, hazard history, schema discovery, attribution, and feed health. Each tool appears to earn its place, though the set is larger than the ideal 3-15 range for a tightly scoped server.

Completeness5/5

The surface is remarkably complete for a read-only emergency/disaster data API: current and historical incidents, event clustering, incident snapshots, nearby queries, declaration lookups by multiple keys, gauge readings and summaries, hazard history, schema enums, attribution, and source feed status are all covered. There are no obvious dead ends or missing core operations for the stated domain.

Resources