septa-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HOST | No | Server transport host | 0.0.0.0 |
| PORT | No | Server transport port | 8000 |
| MCP_TRANSPORT | No | Server transport settings | stdio |
| SEPTA_API_BASE | No | Real-time API base (point at the mock for offline dev) | https://www3.septa.org/api |
| SEPTA_DATA_DIR | No | Where the downloaded schedule is cached | ~/.cache/septa-mcp |
| SEPTA_GTFS_ZIP | No | Use a local gtfs_public.zip / google_rail.zip instead of downloading | |
| SEPTA_GTFS_URLS | No | Comma-separated download URLs | SEPTA, then GitHub |
| SEPTA_API_TIMEOUT | No | Seconds per real-time request | 10 |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| find_stationA | Look up SEPTA Regional Rail stations by (partial) name. Returns matching stations with the lines that serve them. Use this when a station name is ambiguous or you're unsure what the user means. |
| train_scheduleA | Scheduled Regional Rail trains from one station to another on a given day. Args: from_station: Boarding station, e.g. "Jefferson", "30th Street", "Swarthmore". to_station: Destination station. date: "today", "tomorrow", a weekday name ("saturday" = the next Saturday, or today if it is Saturday), or YYYY-MM-DD. depart_after: Earliest departure, e.g. "05:00" or "7:30 AM". Defaults to now when the date is today, otherwise start of day. For "morning" use 05:00–12:00, "afternoon" 12:00–17:00, "evening" 17:00–23:59. depart_before: Latest departure. Defaults to end of service day. max_results: Cap on trains returned. Returns direct trains (train number, departure, arrival, line). If there are no direct trains, returns one-transfer itineraries instead. Times are scheduled, not live; for trips in the next hour or so, also call next_trains for delays. |
| next_trainsB | Next trains from one station to another right now, with live delay status. Uses SEPTA's real-time NextToArrive API (includes connecting trips when there is no direct train). Falls back to the published schedule if the live API is down. |
| station_departuresB | Live departure board for a Regional Rail station: upcoming trains, destinations, delays and track numbers. direction: "N" or "S" as SEPTA labels trains at that station (roughly: N = headed toward the northern end of the system, S = toward the south/west); omit for both. |
| train_statusA | Where a specific train is right now and how late it's running, plus its stop-by-stop estimated times. train_number is SEPTA's train number, e.g. "5305". |
| rail_alertsA | Current SEPTA Regional Rail service alerts and advisories. Optionally filter by line name, e.g. "Media/Wawa" or "Paoli". |
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 6 tools
Each tool has a distinct role: station lookup, station departure board, origin-destination live trains, origin-destination schedules, train status, and alerts. The main possible overlap is between station_departures and next_trains, but the descriptions make the distinction reasonably clear: one station's board versus a specific origin-destination trip.
All tool names use consistent snake_case and are readable. Most are noun-phrase style (station_departures, train_status) while find_station uses verb_noun, which is a minor deviation but not confusing.
Six tools is well-scoped for a Regional Rail information server. Each tool covers a distinct transit query type without unnecessary bloat.
The surface covers the core Regional Rail workflows: station discovery, scheduled trips, live next trains, station departure boards, train status, and service alerts. No obvious operational gap remains for typical rider questions.