MTA MCP Server

The question. Can Claude, on a phone, answer “when is the next downtown Q at 7 Av?” or “is the L running?” from live data, using a server that costs nothing to run?

What I built. A remote, stateless Model Context Protocol server on one Cloudflare Worker on the free plan.

• Three tools: find_station, next_arrivals, and service_alerts.
• Live data: the MTA’s public GTFS-realtime feeds, which need no API key.
• Station data: a Python build script turns the MTA’s static GTFS and the state’s open-data station table into a 496-station index bundled with the Worker.
• Tests: 87 run inside the Workers runtime, plus 18 for the build script.
• Coverage: live subway arrivals and alerts shipped first. Long Island Rail Road and Metro-North followed on September 28, 2026.

What I found. The binding constraint on the free plan was CPU time, not network.

• The problem: the free plan allows 10 ms of CPU per request. On the first deployment, measured median CPU for next_arrivals was 39–43 ms.
• The fix: in a local profile, protobuf decoding was about a third of the CPU. I replaced the full decode with a selective scan that reads only the trips stopping at the requested station. Across 1,164 comparisons it matched the full decode with zero differences.
• The result: on the current deployment, median CPU for a one-feed station fell from 17 ms to 7 ms.
• What is still open: some calls still cost several times the median, and every tool’s CPU rose after the commuter-rail release. I haven’t explained either yet.

The static timetable is 1.21 million stop-time rows. That rules out loading it into the free plan’s database, so the planned next step precomputes departure boards offline and ships them as static files.

Status. Built from September 2026 and still in development. The code is private.