A
licenseNot graded
qualityD
maintenanceProvides tools to search stops, get next departures, and retrieve service alerts from Metlink's real-time public transport data, enabling natural language queries about Wellington transit.
MIT
PTV Transit MCP Server
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@PTV Transit MCP ServerWhat time is the next train from Oakleigh station?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
PTV Transit MCP Server
An MCP server that exposes Victoria's public transport (PTV) GTFS timetable data — trains, trams, and buses — so an LLM (Claude Desktop, Cursor, etc.) can answer natural-language questions about routes, stops, and departure times.
Data at a glance: 1,069 routes · 31,971 stops · 333,875 trips · 12.6 million scheduled stop times, across 8 transport modes (metro train, metro tram, metro bus, regional train, regional bus, regional coach, night bus, SkyBus).
Why this project
Data source: Transport Victoria's GTFS Schedule dataset, published by the Victorian Department of Transport and Planning. It contains static timetable information for all metropolitan and regional trains, buses (including coach), and trams in Victoria, refreshed on a weekly (or as-needed) basis.
This project turns that raw GTFS export into a queryable SQLite database and wraps it in an MCP server with:
Tools for structured lookups (stop search, route listing, next departures)
A guarded raw-SQL tool for open-ended questions, restricted to read-only
SELECTstatements with a hard file-level read-only guarantee underneathA schema resource so the model can write informed queries without guessing column names
A prompt template for trip planning
Related MCP server: gtfs-pro-mcp
Setup (Windows, using uv)
Install
uvif you don't have it:powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"Clone this repo and install dependencies:
git clone https://github.com/MananshuMandaliya/ptv-mcp-server.git cd ptv-mcp-server uv syncDownload the GTFS data: Go to the GTFS Schedule dataset page, download the current
GTFS.zip, and save it as:data/gtfs.zipBuild the database:
uv run python scripts/build_database.pyThis creates
data/ptv.db. It can take a couple of minutes —stop_timesalone typically runs into the millions of rows across all modes.Test it with the MCP Inspector:
uv run mcp dev src/ptv_mcp/server.pyThis opens an interactive UI in your browser where you can call each tool directly and see the raw responses.
Install into Claude Desktop:
uv run mcp install src/ptv_mcp/server.pyRestart Claude Desktop, and you should see this server's tools available in a new conversation.
Example queries once connected
"What time is the next train from Oakleigh station?"
"List all tram routes."
"How many stops does the Frankston line have?" (via the raw SQL tool)
Project structure
ptv-mcp-server/
├── pyproject.toml
├── scripts/build_database.py # GTFS.zip -> SQLite
└── src/ptv_mcp/server.py # the MCP serverDesign decisions
Why SQLite instead of a hosted database? Zero setup for anyone reviewing this project — clone, build, run. No credentials, no hosting cost, no server to keep alive. GTFS is also a natural fit for SQLite: it's a static, read-heavy dataset that's rebuilt from source on a schedule rather than written to at runtime.
Why a nested-zip loader? Victoria's GTFS.zip isn't structured as one folder per mode with plain .txt files — each branch folder (train, tram, bus, etc.) contains its own nested google_transit.zip. The first version of the loader assumed flat .txt files and silently loaded zero rows. Rather than guessing at a fix, I wrote a small diagnostic script to print the actual zip structure, confirmed the nested-zip pattern, then rewrote the loader to open each nested zip in memory (io.BytesIO) rather than extracting to disk.
Why guard run_sql_query at two layers? The tool needs to let the model run arbitrary read-only SQL for questions the structured tools don't anticipate, but "arbitrary SQL from an LLM" is a real risk surface. So there are two independent layers: the SQLite connection itself is opened via a read-only URI (file:...?mode=ro), which SQLite enforces at the file-handle level regardless of what the query says, and a regex guard rejects anything that isn't a single SELECT statement before it's even executed. Either layer alone would probably be enough; both together means one bug in the regex doesn't turn into a write.
Why index stop_id, trip_id, route_id, and service_id? stop_times has 12.6 million rows. Without indexes, get_next_departures was a full table scan on every call. With them, lookups return in well under a second even on this dataset size.
Notes / limitations
This serves the static schedule, not live GPS positions or real-time delays (Transport Victoria separately publishes a GTFS-Realtime feed for that — a natural extension of this project).
The GTFS export contains a rolling window of timetable data from its export date, so
data/gtfs.zipshould be re-downloaded periodically to stay current.
Available Tools
4 toolsget_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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| stop_name | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It usefully reveals that results reflect the static timetable rather than real-time positions, and clarifies that all routes serving the stop are included. It does not cover edge cases like multiple partial matches or sorting, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a compact Args list. It is front-loaded with the purpose, uses a separate note for an important caveat, and has no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read tool with an output schema, the description covers the essential context: what it returns (scheduled departures), scope (all routes), and static nature. It could add sorting order or why one might first use search_stops, but the core information is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section adds meaningful semantics beyond the schema: stop_name is a name or partial name, and limit is the maximum number of departures. Since schema description coverage is 0%, this compensation is important; it could additionally mention default behavior or allowed range.
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 opens with a specific verb ('Get upcoming scheduled departures') and clearly identifies the resource (a given stop across all routes serving it). This distinguishes it from sibling tools like search_stops and list_routes, which target stops and routes rather than departures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a clear use case—upcoming scheduled departures for a stop—and adds a contextual note that it reads static GTFS, not live GPS, which implies it should not be used when real-time delays matter. However, it does not explicitly name alternative tools or provide comprehensive when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| limit | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses important behavior: mode values are enumerated, omitting mode returns all modes, and limit controls max results. It does not mention potential ordering or edge cases, but the listed behaviors add meaningful context beyond the bare schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose followed by a compact Args section. Every sentence adds value, and the format is easy to scan.
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 the tool's simplicity (2 optional parameters), the description fully covers invocation details. An output schema exists, so return values are pre-defined. The mode and limit parameters are completely documented, and the purpose is clear. No critical gaps for selection or invocation.
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?
The input schema has 0% description coverage, so the description must compensate. It does so thoroughly by enumerating all valid mode values, explaining that omitting mode lists all modes, and defining limit as the maximum number of results. This adds significant meaning beyond the schema's bare property names.
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 uses a specific verb ('List') and resource ('public transport routes'), with a clear optional mode filter. It distinguishes itself from sibling tools like search_stops and get_next_departures by focusing on routes rather than stops or departures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what the tool does, but it does not explicitly mention when to use this tool over alternatives (e.g., search_stops, get_next_departures, run_sql_query). No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the read-only nature, the SELECT-only constraint, available tables, and points to ptv://schema for column details. This covers key behavioral traits, though it omits details about limits or error handling, which are less critical given the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a clear one-line purpose, followed by constraints and an args section. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides essential context: available tables, the schema resource for columns, and the intended scope (other tools don't cover). Since an output schema exists, return values are documented elsewhere. Minor gaps like query limits or examples prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining that the query parameter must be a single SQL SELECT statement. This adds essential meaning beyond the property name, though it could benefit from syntax examples or clarifications.
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 clearly states it runs a read-only SQL SELECT query against the GTFS database, distinguishing itself as a direct query tool for questions other tools don't cover. This is a specific verb+resource with explicit differentiation from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for questions the other tools don't cover' provides clear context for when to use this tool, and the constraint that only SELECT statements are permitted implies a read-only use case. However, it does not explicitly name alternatives or list when-not-to-use conditions beyond the general other-tools note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses partial/full name matching and the limit parameter, but does not mention case sensitivity, sorting, or whether the operation is read-only. For a simple search this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one purpose sentence followed by a clear Args block. Each line earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters, and an output schema exists, so return values need not be explained. The description covers purpose and parameters adequately, though it lacks explicit use-case guidance and edge-case notes.
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 description coverage is 0%, yet the description fully compensates by explaining both parameters: query as 'Partial or full stop name to search for' with examples, and limit as 'Maximum number of results to return.' This adds meaning well beyond the bare schema.
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 opens with 'Search for public transport stops/stations by name,' which is a specific verb+resource+scope. The resource (stops/stations) and scope (by name) clearly distinguish it from sibling tools like list_routes and get_next_departures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for stop-name lookups but does not explicitly state when to use this tool vs alternatives, nor does it offer any exclusions or prerequisites. It is functionally distinct from siblings, but the guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A4.3/5.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count4/5
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.
Completeness4/5
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.
Maintenance
ActivityMaintained
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Public Data Ukraine Mcp connects AI agents to real public APIs via MCP. Tools include
Hosted MCP endpoint with realistic fake data for prototyping agents. 12 tools, no setup.
The Ferryhopper MCP server is a connector for LLMs and AI Agents in maritime travel that exposes ferry routes, schedules, and booking options. It enables AI assistants to search ports and connections across 33 countries and 190+ ferry operators, provide real-time ferry itineraries with indicative prices, and assist users with planning island-hopping or multi-leg journeys by processing natural language queries about ferry times, passenger counts, and travel durations.
Hosted MCP server for live public-data APIs and Skills for AI agents.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceMCP server that provides tools for querying live transit data (stops, departures, routes, vehicles, alerts) from any WP GTFS Pro site, enabling AI assistants to answer rider questions.21GPL 2.0
- AlicenseNot gradedqualityBmaintenanceMCP server that integrates with the transport12 API to provide tools for searching stops, routes, arrivals, and vehicle forecasts, enabling natural language interaction with public transport data.12MIT
- AlicenseAqualityCmaintenanceProvides tools for AI agents to query live public transport data for GZM (Silesian Metropolis) including vehicle positions, trip updates, service alerts, and next arrivals.8MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MananshuMandaliya/ptv-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server