TfNSW Trip Planner MCP Server

Overview Schema Source Related Servers Discussions Admin

get_alerts

Check service alerts for any NSW stop or network-wide to avoid disruptions, trackwork, and planned changes. Filter by time, current status, and result count to get only relevant alerts.

Instructions

Retrieve service alerts: disruptions, trackwork and planned changes.

Pass a stop_id whenever you can. A network-wide fetch returns every alert in
NSW — hundreds of them — so results are capped: `count` is the true total
and `returned` is how many are included.

Args:
    when: Optional ISO 8601 date/time to check alerts for; Sydney local time
        if no offset given. Defaults to now.
    stop_id: Restrict to alerts affecting one stop. Omit for network-wide.
    current_only: Only alerts in effect now. Set false to include future ones.
    max_results: Maximum alerts to return.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`when`	No
`stop_id`	No
`max_results`	No
`current_only`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 8, 2026

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that results are capped with count and returned fields, explains timezone handling for the when parameter, and notes default behaviors. It does not mention authentication or rate limits, but for a read-only retrieval tool, this is acceptable.

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 compact and well-structured. It opens with a one-line purpose, gives a critical usage hint, then lists args in a clear block. Every sentence adds value; no redundancy or filler.

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?

All four parameters are covered with practical detail, the cap behavior and return fields are explained, and the timezone handling is specified. Given the output schema exists (which presumably details the full response), this description is complete enough for an agent to call correctly without further clarification.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate. Each parameter is clearly explained: when (ISO 8601 format, default now, timezone), stop_id (restrict to stop or omit), current_only (effect period), max_results (cap). This adds significant meaning beyond the bare schema definitions.

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 clearly states the tool retrieves service alerts (disruptions, trackwork, planned changes) for NSW, which is a specific verb-resource pairing. It is easily distinguishable from sibling tools like get_departures or plan_trip, which serve different purposes.

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 provides clear guidance on when to pass a stop_id versus omitting it for network-wide fetch, and explains the current_only parameter's effect. While it doesn't explicitly name alternative tools (there are none for alerts), it gives solid context on usage scenarios, so no exclusion guidance is needed.

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

Deploy Server