NSW Rural Fire Service major fire incidents.
Scored across 3 tools
incidents_all and major_incidents both return NSW major incidents and differ mainly by tier (PRO full list with status filter vs FREE first 5), which risks misselection when an agent just wants 'current incidents'. near_postcode is clearly distinct, and the descriptions do clarify the PRO/FREE and filter differences, but the overlap between the two listing tools is real.
All names are snake_case, which is good, but the conventions are mixed: incidents_all uses a noun+quantifier, major_incidents is adjective+noun, and near_postcode is preposition+noun. Nothing follows a verb_noun pattern, so an agent cannot infer naming from action.
Three tools is thin for a domain that could support incident detail, status enumeration, and variable-radius queries, and two of the three are near-duplicate listings, leaving effectively two distinct capabilities. It is not a severe mismatch, but the surface feels under-scoped for a PRO-tier data service.
Core listing workflows are covered, but there is no get-incident-by-id or per-incident detail tool, no way to enumerate valid status values, and the proximity query is fixed at 100 km with no adjustable radius. These are notable gaps an agent will hit when it needs details beyond a summary list.
PRO. Full NSW major incidents list with optional status filter.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| access_token | No | Subscriber token from /success (or Authorization: Bearer) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It signals a PRO/paid tier and the schema documents the subscriber token, but it does not disclose return limits, pagination, whether results are cached, or what 'full' means operationally.
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 single sentence is front-loaded with the resource and scope, with no wasted words. The 'PRO.' fragment is terse but effective as a tier signal.
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 no output schema and no annotations, the description should say more. It omits valid status values, return structure, how this differs from 'major_incidents', and any pagination or volume expectations.
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 50%. The description adds useful semantics for 'status' by calling it an optional filter, and the access_token parameter is documented in the schema. However, the description does not list valid status values, leaving the filter domain ambiguous.
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 concrete resource and scope: 'Full NSW major incidents list.' However, 'PRO' is cryptic, and 'full' does not clearly differentiate this tool from the sibling 'major_incidents'; an agent cannot confidently tell which list tool to choose.
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 only notes that a status filter is optional. There is no guidance on when to use this tool versus 'major_incidents' or 'near_postcode', no prerequisites, and no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE. Current NSW RFS major incidents (first 5).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description must carry the behavioral burden; it discloses that results are free and truncated to the first 5, which is useful. It omits auth, refresh cadence, return shape, and pagination behavior.
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?
Extremely concise and mostly front-loaded; 'FREE' is useful but precedes the core purpose. Every element earns its place for a simple 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 zero-parameter, no-annotation, no-output-schema tool, the description is sufficient to select and invoke it. It could clarify what qualifies as a 'major incident' or the return fields, but the cap and source are the key operational details.
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?
Zero parameters, so the baseline is 4; the description appropriately adds no parameter 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 resource and scope ('Current NSW RFS major incidents') and a result cap ('first 5'), so an agent can distinguish it from a general incidents list. It does not explicitly name siblings like incidents_all, leaving some differentiation implicit.
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?
Implies use for current major incidents only, but gives no explicit when-to-use/when-not guidance or alternatives such as incidents_all or near_postcode. The 'FREE' note is cost context, not usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PRO. Incidents roughly near an Australian postcode (100 km).
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | ||
| access_token | No | Subscriber token from /success (or Authorization: Bearer) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the 100 km approximation and Australian scope, but not authentication requirements, read-only behavior, rate limits, or return/pagination behavior; 'PRO.' is cryptic.
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 description is very short and wastes little space, with the core resource and radius stated immediately. The only questionable element is the unexplained leading 'PRO.', which does not clearly earn its place.
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 simple one-required-parameter proximity lookup, the description covers the core scope, and the schema carries the access_token detail. It still leaves output shape and authentication requirements implicit, which is a meaningful gap given there is no output schema and no 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?
The schema describes access_token but leaves postcode undocumented. The description adds useful meaning by identifying the postcode as Australian and tying it to a 100 km proximity radius, though it does not specify postcode format or further explain the token.
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 resource (incidents) and scope (roughly near an Australian postcode within 100 km), so the agent can tell this is a proximity search. It does not explicitly differentiate from incidents_all or major_incidents, and the leading 'PRO.' is unexplained, so it falls short of a 5.
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?
The description implies a use case: find incidents near a postcode. However, it gives no guidance on when to use this instead of incidents_all or major_incidents, and it does not mention prerequisites such as the subscriber token.
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.
incidents_allmajor_incidentsnear_postcodeNSW air quality monitoring sites.
Emergency Victoria public incidents feed.
Active wildfire incidents from the National Interagency Fire Center
Australian data as MCP tools: incidents, gauges, declarations, calendars, police releases, archive.
Add one secure layer between your agents and this server.