traintracker
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NR_PASSWORD | Yes | Network Rail data feeds login password (required for timetables and planning) | |
| NR_USERNAME | Yes | Network Rail data feeds login username (required for timetables and planning) | |
| DARWIN_API_KEY | Yes | Live Departure Board consumer key (required for live times) | |
| NR_SCHEDULE_URL | No | Override if the portal gives a different download link for the full daily extract | |
| RTT_ACCESS_TOKEN | No | Realtime Trains access token (optional; either this or RTT_REFRESH_TOKEN can be set) | |
| RTT_REFRESH_TOKEN | No | Realtime Trains refresh token (optional; either this or RTT_ACCESS_TOKEN can be set) | |
| DARWIN_SERVICE_URL | No | Service Details product URL override (optional) | |
| DARWIN_ARRIVALS_URL | No | Live Arrival Board product URL override (optional) | |
| HTTP_TIMEOUT_SECONDS | No | Upstream request timeout | 15 |
| DARWIN_DEPARTURES_URL | No | Override if your Specification tab differs from the default RDM LDBWS URL | |
| TRAINTRACKER_DATA_DIR | No | Where timetable.sqlite lives (default: $XDG_DATA_HOME/traintracker if set, else ~/.traintracker) | |
| DARWIN_SERVICE_API_KEY | No | Service Details product key (optional) | |
| DARWIN_ARRIVALS_API_KEY | No | Live Arrival Board product key (optional) | |
| MIN_INTERCHANGE_MINUTES | No | Minimum change time for planning | 5 |
| TIMETABLE_MAX_AGE_HOURS | No | Re-download timetable when older than this | 26 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| find_stationB | Look up GB railway stations by name or CRS code, best match first. |
| live_departuresA | Live departure board for the next ~2 hours: expected times, platforms, delays, cancellations. Uses Darwin (National Rail); falls back to RTT or the timetable. |
| live_arrivalsB | Live arrivals for the next ~2 hours. Uses Darwin's arrivals product if configured, then RTT, then booked timetable times. |
| departure_platformA | Which platform one train leaves from. Live platforms are often announced only ~10 minutes before departure at large stations; until then the booked (timetable) platform is returned and flagged as 'booked'. |
| platform_departuresA | The next trains leaving from one platform in the next ~2 hours. A train whose live platform isn't announced yet is matched on its booked platform (platform_source 'booked'), which can still change. |
| timetableA | Booked train times at a station for any date the timetable covers (usually months ahead). Use for future trips; for right now prefer live_departures. |
| service_detailsA | All stops for one train, with live times where available. |
| plan_journeyA | Plan journeys between two stations, with changes up to max_changes. Returns the fastest options first plus the fewest-changes option. Cross-London transfers between terminals are included as approximate walk/Tube links. For today's trains in the next two hours, live Darwin times are added and at-risk connections flagged. |
| data_statusB | Which data sources are configured, how fresh the timetable is, and what to set up. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool targets a distinct station/service/platform resource, and the descriptions clearly separate live departures, platform departures, and a train's platform. The main risk is the departure_platform/platform_departures name pair, which could be confused, but the descriptions disambiguate them well.
Names are consistently snake_case and readable, but they mix noun-style resources (timetable, service_details, data_status) with verb-style actions (plan_journey, find_station). The departure_platform/platform_departures swapped-word pair also breaks a clear naming pattern.
Nine tools is well-scoped for a UK rail information server. Each tool covers a meaningful query type without bloat, and the set feels appropriately sized for both departure boards and journey planning.
The read-only rail domain is well covered: station lookup, live arrivals/departures, platform data, future timetable, per-service details, and journey planning are all present. The data_status tool also gives agents a way to diagnose missing or stale data sources, avoiding dead ends.