Provides access to Transport for London's open data on London Underground, Elizabeth line, London Overground and DLR line statuses, including live status, historical disruption episodes, causes, period statistics, and coverage information.
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., "@Tifa Which London rail lines are disrupted right now?"
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.
Tifa keeps the history of London's rail disruptions. Every minute it records the status of every London Underground, Elizabeth line, London Overground and DLR line from TfL's open data, turns it into disruption episodes (which line, what kind, when it started and ended, what TfL said, and what caused it), and serves the live status and the history to everyone through an open REST API and a remote MCP server for AI assistants.
TfL publishes only the status right now. Tifa remembers it, so you can ask how often the Central line had a signal failure last month, how much of last week the network ran a good service, or what was disrupted on the night the clocks went back.
Live service: https://tifa-api-dh52427ooa-ew.a.run.app
API docs: https://tifa-api-dh52427ooa-ew.a.run.app/docs (interactive), docs/api.md
MCP: https://tifa-api-dh52427ooa-ew.a.run.app/mcp, see docs/mcp.md
Powered by TfL Open Data. Contains data from Transport for London, re-used under TfL's open data terms (based on the Open Government Licence v2.0). Tifa is not affiliated with or endorsed by Transport for London. It uses no TfL logos or roundels. Please credit "Powered by TfL Open Data" when you show data you got from Tifa; every API response and MCP result carries that line.
# what is disrupted right now
curl -s https://tifa-api-dh52427ooa-ew.a.run.app/v1/status | jq '.data.lines[] | select(.good | not) | {name, status, reasons}'
# the Central line's unplanned disruptions in October, with their causes
curl -s 'https://tifa-api-dh52427ooa-ew.a.run.app/v1/disruptions?line=central&from=2026-10-01&to=2026-10-31&planned=false' \
| jq '.data.episodes[] | {start, end, status, cause, reason}'
# how the network did over the last 30 days
curl -s 'https://tifa-api-dh52427ooa-ew.a.run.app/v1/stats?span=30d&end=now' | jq '.data | {good_pct, unplanned, planned, most_disrupted}'Add Tifa to Claude Code (or any MCP client; docs/mcp.md covers the others):
claude mcp add --transport http tifa https://tifa-api-dh52427ooa-ew.a.run.app/mcpRelated MCP server: TFL MCP Server for Poke
The full description is in docs/data-model.md. In short:
Episodes. An episode is a run of polls that saw the same line with the same status severity, planned or not.
It starts at the first poll that saw it and ends at the first poll that did not, so times are accurate to about a
minute. Good Service, No Issues and Service Closed (the end of the day) are never episodes. While an episode is
open its end is null.
The GAP rule. When no poll succeeded for more than 15 minutes (GAP = 900 s), nobody was watching. Every
episode open at the last poll before the gap ends there, marked end_estimated: true, and anything still going on
starts again at the first poll after it. Shorter outages change nothing.
A gap is not good service. Time Tifa did not watch counts neither as good service nor as disruption. Every
percentage is of watched time; /v1/coverage shows what was watched, the gaps, and each failed poll with its
reason. Check it before reading a quiet period as a good one.
Categories. Each severity falls in one category: delays (minor and severe delays, reduced service),
suspended (suspended, part suspended), closure (closed, planned and part closures, not running), other
(special service, diversions, bus service and the rest) and info (information, no step-free access). info
episodes are listed but never counted as disruption.
Causes. Each episode's cause is read from TfL's own reason text by 16 rules (signal failure, faulty train,
track fault, power failure, faulty equipment, customer incident, obstruction, staff shortage, strike, police or
security, fire alert, weather, engineering works, train cancellations, operational restrictions, Network Rail).
Planned works are engineering unless they say otherwise. When nothing matches, the cause is null: unknown, and
shown as such.
Time. Times are UTC (ISO 8601 in the API, epoch seconds in month payloads). Months are UTC calendar months. Days and hours shown to people are London time, so a London day can be 23, 24 or 25 hours long.
All GET, open CORS, JSON in a {"data": ..., "meta": ...} envelope with the attribution in meta. Details,
parameters and examples: docs/api.md.
Route | What |
| Every line's status at the last poll, and the episodes open now |
| What changed since a cursor: for keeping a copy in sync |
| The lines; one line in depth (now, 24 hours to 90 days, recent episodes, hours of the day) |
| The months index; one month's episodes and watched time |
| Episodes filtered by line, time, category, cause and planned, paged |
| Figures for 1, 7, 30, 90 or 365 days, against the period before |
| When Tifa was watching: spans, gaps, polls and failed polls per day |
| Sources, categories, causes, licence and the fair-use limits |
| The last poll's age and the service's health |
| Interactive documentation and the OpenAPI document |
| The MCP server (streamable HTTP, stateless, JSON responses) |
Every answer from a route, errors included, has an ETag (send If-None-Match for a 304), Cache-Control set
per route, and gzip when asked. Refusals by the fair-use limits (429, and 503 for the service-wide limits) and other
errors the service raises before reaching a route (405, 413, 500) are no-store and carry no ETag.
The MCP server at /mcp has seven read-only tools over the same data as the REST API: list_lines,
current_status, line_status, disruptions, period_stats, coverage and causes. No key or sign-in is
needed. Setup for Claude Code, the Claude apps, VS Code, Cursor and others, and the tool reference, are in
docs/mcp.md.
Tifa is free to use and runs on a small budget, so requests are shared out:
Per client address (IPv6 by /64): a bucket of 60 tokens, refilled at 1 per second. A request costs 1,
an uncached changes, disruptions, stats or coverage query 5, an MCP tool call 3. Each address may also receive
1.25 MiB an hour (an eighth of the service's allowance), so ask for gzip and send If-None-Match. Over either:
429 with Retry-After.
For the whole service: 20 requests a second (bursts to 100), 10 uncached computations a second and 10 MiB of
responses an hour. Over: 503 with Retry-After (60 seconds, or longer while the hourly allowance recovers).
Responses carry RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset and RateLimit-Policy.
If traffic still runs away, a guard closes the public API for a while (more than 9,000 requests in 5 minutes: 30 minutes, doubling on repeats up to a day; more than 36,000 in an hour: 2 hours; the month's estimated cost over $2, or the budget spent: until the 1st). Recording never stops.
Polling once a minute is plenty: the data changes at most once a minute. Use If-None-Match, and /v1/changes to
keep a copy.
Source | What | Published |
| Tifa's own live recording of TfL's line status, from its first poll | yes |
| TfL's freedom-of-information release of its status records, 2020 to February 2025 | no |
Historic data from TfL's FOI release is not published. Information released under the Freedom of Information Act
is released to the person who asked: the Act gives access, not a licence to re-use or publish, and TfL's release
grants no such permission. So the API publishes only Tifa's own recording (TIFA_PUBLIC_SOURCES=a, the default
everywhere), and tools/import_foi.py refuses to run unless told --i-have-reuse-permission. If TfL grants re-use
in writing, the history back to 2020 can be added.
Code: MIT (LICENSE).
Data: TfL open data, under TfL's open data terms (based on the Open Government Licence v2.0), with the attribution "Powered by TfL Open Data". Tifa is not affiliated with or endorsed by Transport for London.
No accounts, no keys, no cookies, no analytics, no tracking.
The REST API, /openapi.json and /mcp load nothing from anywhere else. The interactive docs page, /docs, is
Swagger UI: when you open it in a browser, your browser fetches Swagger UI's script and stylesheet (an exact,
pinned version) from the jsDelivr CDN, so the CDN sees your address too. Nothing else on the page asks a third
party. Read docs/api.md or /openapi.json instead to avoid that.
Your IP address is used only for the per-client rate limit. It is held in the API's memory (at most 10,000 addresses, the least recently seen dropped first) and never written to the database or to Tifa's own logs.
Cloud Run's request logs for responses below HTTP 500 are excluded from Cloud Logging, so ordinary requests leave no log entry with your address. Request logs of server errors (5xx) are kept for diagnosis, as Cloud Logging records them.
The fair-use guard reads only aggregate request counts.
Tifa's TfL app key is kept in Secret Manager and never logged.
Cloud Scheduler (every minute, UTC) ──► tifa-poller (private)
├─ GET TfL line status
├─ check the answer, observe, advance: one Firestore transaction
└─ guard: Cloud Monitoring every 2 minutes; can close tifa-api
Budget alerts ─► Pub/Sub ─push─────────► tifa-poller /internal/budget
Anyone ─────────────────────────────────► tifa-api (public): /v1/*, /mcp, /docs, /health
served from memory, refreshed from Firestore every 30 sTwo Cloud Run services from one image (TIFA_ROLE=api|poller), so a flood on the public API can never stall
recording. The poller is private (IAM); the API is public and scales to zero.
Each minute slot is recorded at most once, in one transaction, so retries are harmless. TfL's answer is checked before anything changes, so a broken answer cannot close every episode.
The API serves a copy held in memory, so database reads do not grow with traffic.
Everything needed to run your own Tifa on Google Cloud is in this repository; nothing identifying a real deployment
is. Tifa can share an existing project: every resource it creates is named tifa-* and labelled app=tifa, its CI
identity may update only its two services, and its budget counts only its own resources.
cp infra/env.example infra/.env and fill it in (gitignored; never commit it).
infra/bootstrap.sh --dry-run, then infra/bootstrap.sh: APIs, Firestore, Artifact Registry, service accounts,
Workload Identity Federation for GitHub Actions, the TfL key secret, Pub/Sub and a paused Scheduler job.
In the GitHub repository's settings, set the Actions variables the bootstrap prints (--github sets them with
gh), and create the environment production, limited to the main branch. The Deploy workflow runs in that
environment, so without it every deploy from CI fails.
Optionally register for a free TfL app key on TfL's API portal and store it with infra/bootstrap.sh tfl-key
(a hidden prompt), then set TFL_APP_KEY_VERSION to the version it prints. Without a key, Tifa polls
anonymously.
infra/first-deploy.sh: builds the image and creates both services with your own credentials, and lets CI update
them (and nothing else).
infra/post-deploy.sh: who may call what, the budget and its push, the log exclusion, then smoke tests. From
then on every push to main deploys through .github/workflows/deploy.yml.
Resume the Scheduler job, and recording starts.
docs/operations.md has the details: settings, deploying, rotating the key, the guard and the budget, rolling back and troubleshooting. The services' settings are environment variables, listed in docs/contracts.md.
Expected, in US dollars a month, assuming the free tiers are already used by something else:
Item | Expected |
Poller: 43,800 polls a month of about 3.5 s at 0.25 vCPU | 1.06 |
API: about 100,000 requests | 0.36 |
Cloud Scheduler: one job | 0.10 |
Egress, Artifact Registry, Secret Manager | 0.17 |
Firestore, Logging, Monitoring, Pub/Sub (inside their free tiers) | 0 |
Total | about 1.70 |
Under abuse, the fair-use limits, the guard and a monthly budget (£3.75, about $5, by default) hold the worst case to about the budget. Nothing is ever deleted and billing is never detached; recording carries on while the public API is closed.
uv sync # Python 3.12+; the image uses 3.13
uv run pytest -q # the whole suite; Firestore emulator tests run when FIRESTORE_EMULATOR_HOST is set
uv run ruff check .
TIFA_ROLE=api uv run tifa # the API on http://localhost:8080 with an empty in-memory storetests/integration/ runs three simulated days of minute polls (including the night the clocks go back) and the
night a month ends through the real poller into an in-memory store, and reads them back through the REST API, the
MCP server, clients keeping a copy in sync and the operator tools.
docs/api.md: the REST API
docs/mcp.md: the MCP server
docs/data-model.md: episodes, gaps, categories, causes, months and the period figures
docs/operations.md: setting up, deploying and running it
docs/contracts.md: the internal interfaces
The causes Tifa puts disruptions down to (read from TfL's reason text), as codes with labels, in the order the rules are tried. The codes are what disruptions takes as cause; a disruption with a null cause is unknown (cause=unknown finds those).
Inputs: no named parameters.
When Tifa was watching, over a time range (default: the 7 days to now; at most 90 days): the spans each source covered, the share of the range watched, the gaps nothing watched, and per UTC day the polls recorded (of 1440) and the polls that failed. Check it before reading a quiet period as a good one.
Inputs: to, from.
The status of every line right now, refreshed from TfL each minute: status text, worst severity, TfL's reasons, whether it is good service and whether a problem is live or planned works; lines with live problems first, then planned works, then good service. Also the disruptions open now (with their start times and causes), the time of the last poll, and stale: true when there has been no poll for over 5 minutes (or the history cannot be read), so the status may be out of date.
Inputs: mode.
Recorded disruptions overlapping a time range (default: the 30 days to now; at most 366 days), oldest first. One row per spell of one severity on one line: start, end (null while it is still going on), minutes, severity, status text, category, planned or not, cause and TfL's reason, and whether the end is estimated (recording was paused). Filter by line, category, cause and planned. total is how many match; when next_cursor is not null, call again with it (and the same other arguments) for the next page.
Inputs: to, from, line, cause, +4 more.
One line in depth: its disruptions open now; the number of disruptions, minutes disrupted and share of watched time disrupted over the last 24 hours, 7, 30 and 90 days; its latest disruptions with TfL's reasons and their causes; and the London hours of the day at which its unplanned disruptions start.
Inputs: line (required).
Every line Tifa records, with its id, name and mode (tube, elizabeth-line, overground or dlr) and the lines it shares track with. The ids are what line_status, disruptions and period_stats take.
Inputs: no named parameters.
Figures for a period, for the network or one line: watched coverage, share of time with good service, unplanned and planned disruption counts, line-time disrupted, the change against the period before (when both were at least 80% watched), the most disrupted line, the longest unplanned disruption, the busiest day, the top causes, per-day (or per-week) bins and a per-line table. period names the period and gives prev and next: the end to pass for the period before or after. Unlike the other tools, times here (t0, t1, p0, starts and ends, bins, unwatched spans) are epoch seconds (UTC) as numbers; only period.first is ISO 8601.
Inputs: span (required), end, line.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 7 tools
Each tool has a distinct scope: list_lines and causes are reference lookups, current_status is a network-wide now snapshot, line_status is a per-line deep dive, disruptions is a paged record query, and period_stats/coverage are aggregate analytics. The main risk is overlap between line_status (which includes recent disruptions and per-line counts) and period_stats (which can also produce a per-line table), plus the near-pair naming current_status vs line_status. Descriptions do enough to steer an agent, but the boundary between per-line stats and period stats requires careful reading.
All names are lowercase snake_case, which is consistent, but the grammatical pattern is mixed: list_lines is verb_noun, current_status is adjective_noun, line_status is noun_noun, and disruptions/coverage/causes are bare nouns. The verb-style tools imply actions while the noun-style ones are queries, so an agent cannot infer the calling convention from the name alone. Still readable and domain-conventional.
Seven tools is well within the ideal range for a single-domain read-only analytics server. Each one earns its place: two reference lookups, one live snapshot, one per-line detail, one raw record query, one period aggregation and one data-quality checker. No obvious redundancy or filler.
The surface covers the lifecycle of observed disruption data well: enumerating lines and causes, live status, historical records with filtering and pagination, period comparisons, and coverage/staleness checks. Minor gaps remain — there is no way to fetch a single disruption by id, no manual poll/refresh trigger, and no direct way to explore inter-line (shared track) correlation despite list_lines exposing that information.
Check UK Delay Repay, UK261 flights and TfL refunds. Save claims and check commutes on request.
Belgian trains for AI agents: live journeys, departures, delays, disruptions. Free, no key.
Read-only airport delay, weather, and 24h forecast tools for AI assistants. Airport-level only.
Live UK rail boards, journey planning, train history, units, lifts, disruptions, punctuality.
