TfNSW Trip Planner MCP Server

Overview Schema Source Related Servers Discussions Admin

plan_trip

Plan a public transport journey between two places using place names, addresses, or stop IDs. Choose departure/arrival time, live delays, wheelchair access, and detail level.

Instructions

Plan a public transport journey between two places.

Prefer passing plain place names as `origin` and `destination` — addresses,
stations, suburbs and landmarks all work, and the server resolves them
itself. You do NOT need to call find_stop or best_stop first; doing so costs
two extra round trips for no benefit. Use `origin_id`/`destination_id` only
when you already hold a stop ID from an earlier call.

Args:
    origin: Place to depart from, e.g. "100 Harris Street Pyrmont" or
        "Circular Quay". Resolved server-side.
    destination: Place to arrive at, e.g. "32 Geelong Rd Engadine".
    origin_id: Stop ID to depart from. Alternative to `origin`, not both.
    destination_id: Stop ID to arrive at. Alternative to `destination`.
    when: Optional ISO 8601 date/time, e.g. "2026-08-30T09:15". Without an
        offset this is Sydney local time. Defaults to now.
    arrive_by: Treat `when` as the desired arrival time instead of departure.
    origin_type: Kind of the origin ID. Leave as "any", which resolves stops,
        addresses and POIs alike; "stop" rejects address IDs and returns
        nothing for them.
    destination_type: Kind of the destination ID. Leave as "any".
    realtime: Include live delay information.
    wheelchair: Return only wheelchair-accessible journeys.
    detail: How much to return per journey. "answer" gives only departure,
        arrival, duration, changes and the mode summary — use it for "when
        do I get there" and "how long does it take", which is most questions.
        "summary" (default) adds the legs, each with its times, route,
        platform and any alerts. "stops" adds intermediate stop names.
        "full" adds the map polyline and is very large — pair it with
        max_results=1 or 2 or the call may exceed the client's size limit.
    max_results: Maximum journeys to return.

Input Schema

TableJSON Schema

Name	Required	Default
`when`	No
`detail`	No	summary
`origin`	No
`realtime`	No
`arrive_by`	No
`origin_id`	No
`wheelchair`	No
`destination`	No
`max_results`	No
`origin_type`	No	any
`destination_id`	No
`destination_type`	No	any

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.9/5.0

Behavior5/5

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

No annotations are provided, so the description carries full responsibility. It discloses server-side resolution of place names, timezone handling for `when`, the size risk of `full` detail, and the effect of `origin_type` rejecting address IDs. This is transparent about behavior without hiding edge cases.

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 long but dense with purpose. It front-loads the key guidance (prefer place names, don't call find_stop) before the parameter list. Each parameter explanation earns its place, though a few could be trimmed (e.g., repeating 'leave as any' for both type params). Overall, it's structured and efficient for the tool's complexity.

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?

Given 12 parameters and an output schema (which covers return structure), the description covers everything an agent needs: how to select inputs, what each option does, and practical cautions like the size limit. No gaps in decision-making or invocation remain.

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 explain every parameter, and it does. It clarifies `origin`/`destination` as free-form place names, `when` as ISO 8601 with Sydney local time default, `detail` levels with concrete usage examples, and the mutual exclusivity of ID versus name params. All 12 parameters are meaningfully described.

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 action ('Plan a public transport journey') and explicitly distinguishes it from sibling tools by telling the agent not to call find_stop or best_stop first, and by covering place-name vs ID inputs. This makes the tool's purpose unmistakable and separates it from plan_trip_from_coordinate and others.

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?

Provides explicit guidance on when to use place names versus stop IDs, which alternatives to avoid (find_stop/best_stop), and how to set detail levels based on the question type (e.g., 'answer' for time/duration, 'full' with max_results). This is clear when-to-use and when-not-to-use direction.

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

Deploy Server