rozklad-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ROZKLAD_LIVE | No | Set to `0` to disable live delays. | 1 |
| ROZKLAD_FEEDS | No | Feed groups (`trains`, `regional`/`pks`, `city`), individual feeds (`warszawa`), cities (`city:Kraków`), regions (`region:wielkopolskie`), `all`, exclusions (`-sindbad`). | trains,regional |
| ROZKLAD_CACHE_DIR | No | Where to store the downloaded timetables (defaults to the system cache directory). | |
| ROZKLAD_FEEDS_FILE | No | Custom feed registry file (e.g. in a fork for a single region). | |
| ROZKLAD_MAX_WALK_M | No | Maximum walking distance between stops when transferring, in meters. | 500 |
| ROZKLAD_EXTRA_FEEDS | No | Custom GTFS files, e.g. `moj-pks=https://…/gtfs.zip;inny=https://…`. | |
| ROZKLAD_MIN_TRANSFER | No | Minimum transfer time in minutes. | 4 |
| ROZKLAD_REFRESH_HOURS | No | How often to check for new timetables, in hours. | 12 |
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": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| plan_journeyA | Find connections between two places in Poland, including changes between trains and buses (PKS). from/to accept a station name ("Poznań Główny"), a town ("Zakopane" = all its stops) or coordinates "52.40,16.91". Returns several options with times, platforms, operators, changes and live delays (today). |
| departuresA | Departure (or arrival) board for a station or stop: time, live delay, train/bus line, platform, destination and main stops. Optionally only services going towards a given place. |
| trip_detailsA | All stops of one train or bus run with times, platforms and live delays/cancellations. Identify it by |
| find_stopsA | Search stations/stops by name (fuzzy, diacritics optional). Shows modes, coordinates and source feeds. |
| nearby_stopsB | Stations and stops within a radius of coordinates (e.g. after geocoding an address). |
| data_sourcesB | Which carriers/feeds are loaded, their validity dates, licences and required attribution; which feeds can be enabled. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| plan_trip | Plan a door-to-door trip by train/bus |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a clearly distinct purpose: journey planning, departure boards, trip details, stop search by name, stop search by coordinates, and data source metadata. The boundaries are well defined, and descriptions clarify how tools relate (e.g., ref from plan_journey/departures). No tool overlaps significantly with another.
All names use snake_case consistently, which aids readability. However, the set mixes verb-led names (plan_journey, find_stops) with noun-led names (data_sources, departures, trip_details, nearby_stops), a minor deviation from a single pattern.
Six tools are well-scoped for a journey-planning server covering routing, stop lookup, real-time boards, trip details, and metadata. Each tool has a clear, non-redundant role without obvious padding or missing essentials.
The surface covers core operations: find stops, plan journeys, get departures/arrivals, inspect trip details, and discover data sources. Minor gaps exist, such as no dedicated tool for service alerts/disruptions or line-level schedule queries, but agents can work around these using available tools.