Skip to main content
Glama

transport_gzm

MCP server wrapping the GTFS-RT live transit feed for GZM (Górnośląsko-Zagłębiowska Metropolia) — the Silesian Metropolis public transport operator in Poland.

Provides a small, focused set of tools so AI agents can answer questions like:

  • "What buses/trams are currently running on route X?"

  • "Is vehicle Y delayed? Where is it right now?"

  • "What alerts are currently active (delays, disruptions, works)?"

  • "When does the next departure of line 6 arrive at stop Z?"

How it works

GZM publishes a public GTFS-RT feed at https://gtfsrt.transportgzm.pl:5443/gtfsrt/gzm (no auth, CC-BY licensed). It exposes three logical sub-feeds:

Path

Content

/gtfsrt/gzm/all

full bundle (all three sub-feeds)

/gtfsrt/gzm/vehiclePositions

live GPS positions of every vehicle

/gtfsrt/gzm/tripUpdates

arrival-time deltas and stop-skips

/gtfsrt/gzm/alerts

service alerts (works, delays, etc.)

This server fetches the protobuf, decodes it, and exposes it as 9 tools that return JSON-friendly structures sized for LLM context windows.

Static GTFS join (why it matters)

The GZM GTFS-RT feed is minimal: trip descriptors carry only a trip_id (no route_id), and stop-time updates carry only relative delays — no absolute times and no stop_id. To answer "which line is this bus" or "when does the next tram leave stop X", the server additionally loads:

  • Static GTFS — daily mirror at github.com/TransportGZM-GTFS-mirror/TransportGZM-GTFS-extended-ver (same id space as the RT feed; verified). Downloaded once and cached for GZM_STATIC_TTL_HOURS (default 24 h).

  • SDIP live departures — GZM's own passenger-information system behind rj.transportgzm.pl, which powers the real departure boards. The stop directory (/api/v2/stops/data/, ~7 150 poles) is coordinate-matched to GTFS stops at load time.

Related MCP server: PTV Transit MCP Server

Quick start

docker run -i --rm ghcr.io/wiktor102/transport-gzm:latest

Wire it into your MCP client (Claude Desktop, opencode, …):

{
  "mcpServers": {
    "transport-gzm": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "ghcr.io/wiktor102/transport-gzm:latest"]
    }
  }
}

Run from source

pip install -e .
transport-gzm

…or with uv:

uv run --with mcp[cli] --with gtfs-realtime-bindings --with httpx \
  python -m transport_gzm.server

Tools

Tool

Purpose

health

Check feed availability + report feed age

feed_summary

Counts of vehicles, trips, alerts currently in the feed

vehicles

Search/filter live vehicle positions (by route, stop)

vehicle_by_id

Get a single vehicle's current position

trip_updates

Arrival predictions; filter by route, stop, or trip

next_departures

Live departure board per stop (GZM SDIP, minutes)

search_stops

Find stops by name → rj_stop_id / gtfs_stop_id

alerts

Active service alerts (works, delays, detours)

alert_by_id

One alert by id

See docs/tools.md for full parameter documentation and output schemas.

Configuration

Env var

Default

Purpose

GZM_FEED_BASE_URL

https://gtfsrt.transportgzm.pl:5443/gtfsrt/gzm

Override the base URL

GZM_HTTP_TIMEOUT

10

HTTP timeout in seconds

GZM_CACHE_TTL

10

In-process feed cache TTL in seconds

GZM_MAX_VEHICLES

200

Default cap for vehicles()

GZM_MAX_TRIPS

200

Default cap for trip_updates()

GZM_MAX_ALERTS

100

Default cap for alerts()

GZM_USER_AGENT

transport-gzm-mcp/0.1 (+https://github.com/Wiktor102/transport-gzm)

Outgoing UA

GZM_STATIC_DATASET_URL

GitHub mirror ZIP of the extended GTFS

Static schedule source (must share the RT trip-id space)

GZM_STOP_DIRECTORY_URL

https://rj.transportgzm.pl/api/v2/stops/data/

SDIP stop directory

GZM_SDIP_BASE_URL

https://rj.transportgzm.pl/api/-

Live departures board base URL

GZM_STATIC_TTL_HOURS

24

How long to cache the static GTFS index

GZM_COORD_MATCH_TOLERANCE_M

20

Max distance for rj→GTFS stop matching

LOG_LEVEL

INFO

DEBUG / INFO / WARNING / ERROR

License

MIT. GTFS-RT data © Górnośląsko-Zagłębiowska Metropolia, CC-BY 4.0.

Available Tools

8 tools
alert_by_idA

Get a single alert by entity id (e.g. from a previous alerts() result).

Inputs: alert_id (required).

alertsA

List active service alerts (planned works, delays, detours, stop closures). Use this for 'is the tram line broken?', 'any works today?', 'why is my bus late?'.

Inputs: limit, stop_id, route_id.

feed_summaryA

Get the current counts of vehicles, trip updates and alerts in the live feed. Cheap; does not return full payloads.

Inputs: no named parameters.

healthA

Check whether the GZM live transit feed is reachable and report how old it is. Call this first if a query seems to return empty results — it can distinguish 'no vehicles right now' from 'upstream is down'.

Inputs: no named parameters.

next_arrivalsA

Get upcoming arrivals at a specific stop, across all routes, sorted by predicted arrival time. Equivalent to a digital departure board. Returns the 'minutes_from_now' field already computed for you.

Inputs: stop_id (required), limit, route_id.

trip_updatesA

List live trip updates: scheduled vs predicted arrival times and any stop-skips. Use this for 'is line 6 delayed', 'what time does the next bus arrive', or 'is stop X skipped'.

Inputs: limit, stop_id, trip_id, route_id.

vehicle_by_idA

Get a single vehicle's current position by its vehicle id or label (e.g. fleet number painted on the bus, or the entity id from a previous vehicles() call).

Inputs: vehicle_id (required).

vehiclesA

List live vehicle positions (buses, trams, trains) currently running. Use this when the user asks 'what's running', 'where is line X', or 'find a bus to Y'. Returns up to limit vehicles, newest first by timestamp.

Inputs: limit, stop_id, route_id.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.2/5.0

    Scored across 8 tools

    Disambiguation5/5

    Each tool has a distinct purpose: alerts vs alert_by_id, vehicles vs vehicle_by_id, next_arrivals for stop-specific predictions, trip_updates for delay info, feed_summary for metadata, and health for system status. No two tools overlap in functionality.

    Naming Consistency4/5

    Tools follow a clear pattern: plural names for list operations (alerts, vehicles, trip_updates) and 'by_id' for single items (alert_by_id, vehicle_by_id). feed_summary and health are unique but descriptive. next_arrivals deviates slightly but remains intuitive.

    Tool Count5/5

    With 8 tools, the server is well-scoped for a transit data API. It covers all necessary operations without redundancy or bloat, making it efficient for agents to navigate.

    Completeness4/5

    The tool set covers core real-time transit data: vehicle positions, alerts, trip updates, stop arrivals, and system health. Missing static data like route or stop listings, but for live monitoring, it is sufficiently complete.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      C
      maintenance
      Enables AI agents to access real-time public transport data for Moscow and the Moscow region, aggregating and reconciling information from multiple sources. Provides tools for finding stops, live arrival boards, vehicle tracking, route details, and ETA calculations.
      MIT
    • A
      license
      A
      quality
      B
      maintenance
      Connects AI assistants to live public transport data across Great Britain, enabling searches for stops and stations, real-time bus and rail departures, live vehicle positions, service disruptions, and door-to-door journey planning. All tools are read-only and require an API key.
      10
      29 PyPI
      MIT