An MCP server for SEPTA Regional Rail that combines timetable data with live service information to answer schedule, delay, location, and alert questions.
Look up SEPTA Regional Rail stations by partial or ambiguous name and see which lines serve them.
Get scheduled trains between stations for a given date and time window, including direct trains or one-transfer itineraries.
Get the next trains between stations right now, with live delay status and schedule fallback.
View a station's live departure board, including destinations, delays, track numbers, and direction filtering.
Check a specific train's live position, lateness, and stop-by-stop estimated times.
Read current Regional Rail service alerts and advisories, optionally filtered by line.
Handles through-routed trains, station-name differences between feeds, and partial-service/shuttle situations; Regional Rail only.
Click on "Deploy 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., "@septa-mcp When's the next train from 30th Street to Paoli, and is it late?"
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.
An MCP server that lets Claude answer questions like:
"What times do trains leave Jefferson for Swarthmore on Saturday morning?"
"When's the next train from 30th Street to Paoli, and is it late?"
"Where is train 5305 right now?"
"Any problems on the Media/Wawa line today?"
It combines SEPTA's published GTFS timetable (for any date in the current schedule) with SEPTA's real-time API (live delays, tracks, train positions, alerts).
Tool | Source | Use it for |
| GTFS | Timetable questions for any day. Falls back to one-transfer itineraries when there's no direct train. |
| Live (NextToArrive) | "Next train" right now, with delay status. Falls back to the timetable if the live API is down. |
| Live (Arrivals) | A station's departure board: destinations, delays, track numbers. |
| Live (TrainView + RRSchedules) | Where a train is, how late, stop-by-stop estimates. |
| Live (Alerts) | Service advisories and disruptions. |
| GTFS | Resolving vague or ambiguous station names. |
Station names are matched loosely: "Jefferson", "Market East", "30th Street", "Temple", "Mt Airy" all work. Ambiguous names ("Chestnut Hill", "Airport", "Norristown") return the candidates so Claude can ask which one you mean.
train_schedule("Jefferson", "Swarthmore", "saturday", "05:00", "12:00") against the
v202609271 feed returns trains 5301, 5305, 5309, 5313, 5317 and 5321, leaving Jefferson at
:38 past each hour from 6:38 AM and arriving at Swarthmore 35 minutes later.
When no train reaches the destination (e.g. buses replace trains on the last stretch of a
line), results list the alerts for the line plus partial_service: the trains to the
closest station on the way that trains still reach, where riders change to the shuttle.
Related MCP server: mcp-bart
Through-routed trains. Most Regional Rail trains change line name in Center City (a Lansdale/Doylestown train becomes a Media/Wawa train at Suburban Station). GTFS models this as two trips joined by an in-seat transfer, so a naive "trips serving both stations" query finds only a handful of the Jefferson → Swarthmore trains. This server stitches those trips back together, so you see every train.
Trains are reported by number and final destination, the way platform boards list them,
rather than by line. The line name a train has at your boarding station can belong to the
other half of its run, e.g. a Suburban → Claymont train shows up as "Chestnut Hill East".
Station names differ between feeds. The real-time API predates the current GTFS and
uses older names for about 30 stations ("Temple U", "30th Street Station", "Ft Washington",
"Elwyn Station"), and its endpoints don't even agree with each other (NextToArrive wants
"Wayne Station", Arrivals wants "Wayne"). realtime.py translates automatically; the map is
checked against the live API by tests/test_live.py.
Requires Python 3.11+.
pip install .
septa-mcp --transport http --port 8000 # Streamable HTTP at http://localhost:8000/mcp
septa-mcp # stdio, for local MCP clientsOn first start it downloads the rail schedule (≈750 KB) from SEPTA, falling back to
SEPTA's GitHub releases, and re-checks daily. SEPTA publishes a new feed every few weeks;
results include valid_from/valid_until, and a warning if you ask about a date outside it.
A feed's version is named for its start date, and SEPTA folds later schedule changes into the
same feed, so results also list timetable_changes_included to show the data is current.
The repo includes a .mcp.json, so starting claude in a checkout loads the server from
your working copy. It needs uv, which builds a .venv from
uv.lock on first start and installs the package in editable mode:
git clone https://github.com/ellbur/septa-claude-connector && cd septa-claude-connector
claude # approve the "septa" server when prompted, then check with /mcpCode edits take effect the next time the server starts: restart Claude Code, or reconnect
from /mcp.
Claude's custom connectors need a public HTTPS URL, so deploy the server somewhere first. The included Dockerfile works on any container host (Fly.io, Render, Railway, Cloud Run, a VPS behind Caddy, etc.):
docker build -t septa-mcp .
docker run -p 8000:8000 -v septa-data:/data septa-mcpThen add a custom connector in Claude's settings with the URL
https://<your-host>/mcp. No authentication is required: everything it serves is SEPTA's
public data and every tool is read-only.
For local use only, point a desktop MCP client at the stdio command instead:
{
"mcpServers": {
"septa": { "command": "septa-mcp" }
}
}Env var | Default | Purpose |
|
| Where the downloaded schedule is cached |
| — | Use a local |
| SEPTA, then GitHub | Comma-separated download URLs |
|
| Real-time API base (point at the mock for offline dev) |
|
| Seconds per real-time request |
|
| Server transport settings |
uv run --extra dev pytest -q # or: pip install -e ".[dev]" && pytest -q
SEPTA_LIVE=1 pytest -q tests/test_live.py # against SEPTA's real serversSchedule tests run against the real GTFS feed (downloaded, or SEPTA_GTFS_ZIP).
Real-time tests use tests/mock_septa_api.py, which serves responses in SEPTA's format;
you can also run it standalone for offline development.
Regional Rail only. Buses, the Metro (subway/trolley) lines, NJ Transit and Amtrak are not covered. The bus/Metro GTFS is in the same SEPTA download if you want to extend it.
Transfer itineraries are limited to one transfer; that covers any pair of Regional Rail stations.
SEPTA's real-time API is unofficially documented and its response formats occasionally
shift; realtime.py parses defensively but is the first place to look if a live tool breaks.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, so safety is covered. The description adds real behavioral context beyond that: matching is by partial name and results include the lines that serve each station, which tells the agent what it gets back. It doesn't cover empty-result behavior or how fuzzy the matching is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the verb+resource and followed by the return content and the disambiguating use case. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly explains the return shape (matching stations plus serving lines). For a single-parameter lookup tool that's nearly sufficient; only match semantics and no-result behavior are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter and schema coverage is 0%, so the description must carry the load. It does indicate the query is a (partial) station name, which is genuinely useful, but leaves unclear whether matching is case-insensitive, prefix, or arbitrary substring.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Look up SEPTA Regional Rail stations') plus scope ('by (partial) name') and what it returns. The name and description together let an agent separate it from station_departures, train_schedule, and next_trains, which all operate on a known station rather than discovering one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear triggering condition: use it when a station name is ambiguous or the user's intent is unclear. It does not explicitly name the alternative to call once the station is resolved (e.g. station_departures), so the routing is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| to_station | Yes | ||
| from_station | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and open-world behavior, so the bar is lower. The description still adds real value beyond them: it names the upstream data source (SEPTA NextToArrive), discloses that connecting trips are synthesized when no direct train exists, and documents graceful degradation to the published schedule if the live API is down.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with the primary capability front-loaded and the implementation/fallback details trailing. Nothing is redundant, though the API name (NextToArrive) is somewhat implementation-oriented relative to agent decision-making value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should indicate what comes back; 'with live delay status' hints at delay fields but omits the return shape, ordering, or whether connecting legs are returned as separate segments. For a live-data tool where degraded mode changes result semantics, station-format and result-count guidance are the main missing pieces.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of parameter meaning. It conveys the from→to direction but says nothing about station identifier format (abbreviation vs. full name, which matters given the find_station sibling) or what 'count' controls, and the default of 5 appears only in the schema with no explanation of result-set behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — next trains from one station to another right now, with live delay status. The temporal qualifier ('right now') implicitly separates it from train_schedule, but it never names a sibling explicitly, so an agent must still infer its boundary against station_departures (same station) and train_schedule (published times).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by 'right now' plus the schedule-fallback note, which signals this is the live/imminent-departures tool. There is no explicit statement of when to prefer station_departures, train_schedule, or train_status, and no prerequisite guidance (e.g., resolving station names via find_station first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current SEPTA Regional Rail service alerts and advisories. Optionally filter by line name, e.g. "Media/Wawa" or "Paoli".
| Name | Required | Description | Default |
|---|---|---|---|
| line | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds that only current/active alerts are returned, which is useful freshness context, but says nothing about ordering, expiry windows, or what an alert record contains. With annotation coverage this is adequate, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, with the resource stated first and the optional filter second. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-param read-only tool with no output schema and full annotation coverage, the description gives everything needed to invoke it correctly. The only mild gap is that the shape/scope of returned alerts is undescribed, which matters somewhat for an open-world feed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — the schema only labels the property 'Line' with no description — so the description must carry the weight, and it does: it identifies the parameter as an optional line-name filter and supplies concrete example values ('Media/Wawa', 'Paoli'). It stops short of stating behavior for an unknown or mismatched line name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and verb: 'Current SEPTA Regional Rail service alerts and advisories.' The subject matter is clearly distinct from siblings like station_departures, next_trains, and train_schedule, though no sibling is explicitly named or excluded.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the word 'Current' — fetch this for active disruptions — but there is no explicit when-to-use, when-not-to-use, or routing to any alternative tool. An agent can infer the context but gets no guidance on combining it with train_status or train_schedule lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| station | Yes | ||
| direction | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds useful behavioral context by saying it is a live board with delays and track numbers, but it does not mention freshness, rate limits, or whether station matching is exact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then spends its remaining space on the parameter most likely to be misunderstood. Every sentence is relevant, and the direction explanation is appropriately compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, the description gives enough about what the live board returns: upcoming trains, destinations, delays, and track numbers. It is nearly complete, though it could mention count behavior or station naming expectations to remove remaining ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden for parameter meaning. It does a good job explaining the non-obvious direction parameter, including N/S semantics and omission behavior, but it does not explain count or clarify the expected station identifier format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb/resource: a live departure board for a Regional Rail station, listing upcoming trains, destinations, delays, and track numbers. It is clearer than a vague 'get departures' definition, but it does not differentiate itself from the sibling tool next_trains, which may cover similar ground.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the direction parameter but gives no guidance on when to choose station_departures over siblings like next_trains, train_schedule, or train_status. Usage for live departures is implied, but there is no explicit when-to-use or 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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | today | |
| to_station | Yes | ||
| max_results | No | ||
| depart_after | No | ||
| from_station | Yes | ||
| depart_before | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real context beyond the readOnly/idempotent annotations: results are scheduled not live, direct trains are preferred, and one-transfer itineraries are returned as a fallback. Return fields (train number, departure, arrival, line) are also named. Minor gap: no mention of what happens when max_results truncates results or when no service exists at all.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose sentence followed by tightly organized per-argument documentation; each line adds information. The Args-style formatting is slightly verbose for a description field but not padded with filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description explains the return shape, the fallback behavior, and the freshness limitation, and cross-references the sibling for live data. An agent has everything needed to call this correctly on the first attempt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry all parameter meaning, and it does: station examples, accepted date formats with the weekday-name resolution rule, time formats with default resolution logic for depart_after and depart_before, and time-of-day bucket guidance. This is exactly the compensating detail required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with scope: 'Scheduled Regional Rail trains from one station to another on a given day.' This clearly separates it from station_departures (single-station) and next_trains (live/near-term) without needing the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes near-term queries to next_trains ('for trips in the next hour or so, also call next_trains for delays'), which is a genuine when-to-use signal. It does not explicitly contrast with station_departures or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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".
| Name | Required | Description | Default |
|---|---|---|---|
| train_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and openWorld, so the safety profile is covered. The description usefully adds that this covers live position, current lateness, and per-stop estimates, but says nothing about data freshness, what happens for an unknown or non-running train number, or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the returned data, followed by the one bit of parameter guidance needed. No filler or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must convey the return content, and it does: current position, delay, and stop-by-stop estimates. The main remaining gap is failure behavior for an invalid or inactive train number, which mildly matters for a single required-parameter lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the parameter alone, and it does: train_number is identified as SEPTA's train number with a concrete example ('5305'). Only the format constraints (length, leading zeros, validity) remain unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete resource (a specific train) and what is returned: real-time position, delay, and stop-by-stop ETAs. That implicitly separates it from static siblings like train_schedule and next_trains, but no sibling is named, so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the described content — an agent can infer this is for live status rather than a timetable. There is no explicit 'use this when...' or exclusion pointing to train_schedule or next_trains for adjacent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0find_stationnext_trainsrail_alertsstation_departurestrain_scheduletrain_statusScored 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.
SEPTA MCP — Philadelphia SEPTA real-time transit (www3.septa.org/api, keyless)
Belgian trains for AI agents: live journeys, departures, delays, disruptions. Free, no key.
tri-train is a training platform for triathletes that syncs activities from Strava and Garmin and exposes them to Claude through a remote MCP server. Ask Claude how your last block went, why your run pace dropped, or whether you are fresh enough for Sunday's race, and it answers from your real data: activities with laps and grade-adjusted pace, weekly load and the performance management chart (CTL/ATL/TSB), sleep, HRV and resting heart rate, and your race calendar with predictions. Claude can also act: create and adjust planned workouts with structured intervals, push them to your Garmin watch, add races and write notes. Every change is journaled and can be undone. Read and write access are separate OAuth scopes, and the server enforces them on every call. Built and hosted in Switzerland by a triathlete; data stays on our own servers (Swiss revDSG / GDPR).
Real-time BART departures, trip planning, fares, stations, and advisories.
