PTV Transit MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 |
|---|---|
| search_stopsA | Search for public transport stops/stations by name. Args: query: Partial or full stop name to search for, e.g. "Flinders" or "Oakleigh". limit: Maximum number of results to return. |
| list_routesA | List public transport routes, optionally filtered by mode. Args: mode: One of "metro_train", "metro_tram", "metro_bus", "regional_train", "regional_bus", "regional_coach", "skybus", "night_bus". Omit to list across all modes. limit: Maximum number of results to return. |
| get_next_departuresA | Get upcoming scheduled departures for a given stop, across all routes serving it. Note: this reads the static GTFS schedule (not live GPS positions), so results reflect the timetable, not real-time delays. Args: stop_name: Name (or partial name) of the stop/station to look up. limit: Maximum number of departures to return. |
| run_sql_queryA | Run a read-only SQL SELECT query against the GTFS database directly, for questions the other tools don't cover. Only SELECT statements are permitted. Available tables: routes, stops, trips, stop_times, calendar (each has a gtfs_mode column identifying the transport mode). Use the ptv://schema resource to see column details. Args: query: A single SQL SELECT statement. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| trip_planner | A reusable prompt template for planning a trip between two stops. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| get_schema | Returns the column names and types for every table in the database, so the model can write informed run_sql_query calls without guessing at column names. |
TDQS
Scored across 4 tools
Each tool has a distinct purpose: searching stops, listing routes, fetching departures, and running raw SQL queries. Despite get_next_departures taking a stop name, it clearly returns departures not stops, so there is no ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case: search_stops, list_routes, get_next_departures, run_sql_query. This is uniform and predictable.
Four tools is on the lower end of the typical range, but each covers a fundamental need for a transit information server. The count feels slightly thin yet not unreasonable for the scope.
Core operations are covered: stop search, route listing, and departures. Missing features like route-specific stop lists or trip planning are mitigated by run_sql_query, which allows direct access to the GTFS database. No critical dead ends.