A London Transport MCP Server with Cloudflare Workers AI

A remote MCP server for Cloudflare Workers that exposes live Transport for London data as agent tools. Deploy it to your own Cloudflare account, connect it to Claude, the Workers AI Playground, or any MCP client, and ask things like:

Can I get from SW1A 1AA to EC2M 7PY by 9am, and is the Piccadilly line behaving?

How to get to Waterloo from Uxbridge High Street before 6pm?

Give me a summary of current disruptions across the whole London rail network.

Overview

This server gives any MCP client live awareness of the London transport network. Connect it, and an assistant can check line status, plan a journey between two locations, and get a plain-English summary of current disruption, all from real-time Transport for London data.

It runs entirely on Cloudflare's edge: a stateful MCP server built on the Agents SDK, backed by a Durable Object for per-session state, calling the TfL REST API and using Workers AI for on-edge summarisation. The focus is the tool layer rather than a chat UI, since that is the part an assistant actually needs and the part most worth getting right. Clone it, deploy it to your own account, and connect your client.

Tools

Tool	What it does
get_line_status	Current status of any tube, DLR, Overground, Elizabeth line or tram line, with disruption reasons, compacted from TfL's verbose payload into an agent-friendly schema
plan_journey	Journey options between two locations via the TfL Journey Planner, with self-resolving disambiguation (see below), per-leg disruptions, and optional arrive-by time
disruption_briefing	A plain-English network briefing generated by Llama 3.3 70B on Workers AI, grounded strictly in the live status data (source data returned alongside for verification)

Journeys resolve most precisely with postcodes (for example SW1A 1AA to EC2M 7PY), since a postcode maps to a single point. Free-text station names also work and are disambiguated automatically, as described below.

Architecture

MCP client (Claude, Playground, inspector)
        │  streamable HTTP /mcp (or /sse)
        ▼
Cloudflare Worker ── McpAgent (Agents SDK)
        │                │
        │                └── Durable Object (per-session state, SQLite)
        ├── TfL Unified API (REST)
        └── Workers AI (@cf/meta/llama-3.3-70b-instruct-fp8-fast)
                └── optional AI Gateway (caching, logs, rate limits)

Design decisions

• Compact, typed tool outputs. TfL responses are stripped to the fields an agent needs. Smaller payloads mean cheaper, more reliable downstream reasoning.

• Self-resolving inputs, no silent assumptions. TfL's Journey Planner answers ambiguous free-text names (which is most station names, "Waterloo" alone matches three places) with an HTTP 300 disambiguation payload rather than a result. The tool treats that as data, not an error: it ranks the candidates, preferring actual transport stops over roads and points of interest, and retries once automatically with the best match, so the calling agent gets journeys instead of a clarification round trip. Crucially, the response then carries an assumedLocations field naming exactly which stations were assumed. The agent can surface that to the user, keeping the speed of auto-resolution without the trust cost of a silent guess. If nothing resolves after one retry, the tool falls back to returning the candidate list with a retry hint, and it never retries more than once, so a bad input can't loop.

• Grounded generation. The AI briefing is instructed to use only the supplied status data and the raw source data is returned with it, so the output is verifiable rather than plausible.

• Configurable model. The briefing runs on @cf/meta/llama-3.3-70b-instruct-fp8-fast, chosen as a good balance of quality and speed on Workers AI for short summarisation. It's set in one place in src/index.ts and can be swapped for any other Workers AI text model to trade off quality, latency, and cost. AI Gateway can sit in front of inference for caching and observability.

Deploy your own

Requires a Cloudflare account (the free plan is enough) and Node.js.

git clone https://github.com/qpsamet/tfl-mcp-server
cd tfl-mcp-server
npm install
npx wrangler dev        # run locally
npx wrangler deploy     # deploy to <name>.<subdomain>.workers.dev

Optional configuration:

npx wrangler secret put TFL_APP_KEY   # free key from api-portal.tfl.gov.uk, raises rate limits
# Set AI_GATEWAY_ID as a var in wrangler.jsonc to route AI calls through AI Gateway

Once deployed, connect any MCP client to https://<your-worker>.workers.dev/mcp, or test the tools in the Workers AI Playground.

Testing with the MCP Inspector

The MCP Inspector is the quickest way to exercise the tools directly:

npx @modelcontextprotocol/inspector

It opens a local UI in your browser. Set the transport to Streamable HTTP, enter your server URL ending in /mcp (local http://localhost:8787/mcp, or your deployed https://<your-worker>.workers.dev/mcp), and connect. List the tools, then call them with your own inputs.

Stack

Cloudflare Workers, Agents SDK (McpAgent), Durable Objects, Workers AI, AI Gateway, TypeScript, Zod, TfL Unified API.

Data: Powered by TfL Open Data. Contains OS data © Crown copyright and database rights, and Geomni UK Map data © and database rights.

License

Distributed under the MIT License. See LICENSE for more information.