Transitland MCP Server

Global transit via Transitland v2 — operators, GTFS/GTFS-RT/GBFS feeds, routes, stops, departures. That is what the transitland mcp server brings to an AI assistant: the same capability, reachable through the Model Context Protocol rather than a separate app or dashboard.

The short version

• Declarative tool and resource definitions — single file per primitive, framework handles registration and validation
• Unified error handling — handlers throw, framework catches, classifies, and formats, with typed per-tool error contracts and agent-facing recovery hints
• Pluggable auth: none, jwt, oauth
• Swappable storage backends: in-memory, filesystem, Supabase, Cloudflare KV/R2/D1
• Structured logging with optional OpenTelemetry tracing
• STDIO and Streamable HTTP transports — runs locally or on Cloudflare Workers from the same codebase

Getting it running

Because this one is hosted, setup is mostly authentication — you point your client at the endpoint and approve access. Nothing runs on your machine, so there is no runtime to keep patched.

The tools it exposes

The server publishes 8 tools. What each one is for:

• transitland_find_operators — Find transit operators/agencies by name, point/radius, bounding box, country/region, or Onestop ID. The entry point for "what transit runs here?"
• transitland_get_operator — Fetch the full operator record by Onestop ID — agencies, places served, published feeds, and source tags (Wikidata QID, US NTD ID, social handles)
• transitland_find_feeds — Discover GTFS, GTFS-Realtime, and GBFS feeds — fetch URLs, license terms, and last-fetch freshness. Where to legally get a place's open transit data
• transitland_find_routes — Find routes by point/radius, bounding box, operator, Onestop ID, or GTFS mode. Returns name, mode, brand color, and operating agency
• transitland_find_stops — Find stops/stations by point/radius, bounding box, Onestop ID, or operator network. Returns coordinates, location type, accessibility, and timezone
• transitland_get_departures — Departures from a stop, each flagged realtime true/false — live GTFS-Realtime predictions distinguished from static schedule, per departure
• Prerequisites — The Prerequisites tool exposed by this server
• Installation — The Installation tool exposed by this server

What it needs from you

Configuration is passed through the environment: MCP_TRANSPORT_TYPE, MCP_LOG_LEVEL, TRANSITLAND_API_KEY, TRANSITLAND_BASE_URL, MCP_HTTP_ENDPOINT_PATH. Treat anything key-shaped as a real credential — scope it to the minimum the server needs, and rotate it if it ever lands in a shared config.

• Bun v1.3.11 or higher (or Node.js v24+). - A Transitland v2 API key — register at the Transitland developer portal. The free tier is rate-limited; the Pro tier raises the quota.

Things to watch

• Your data travels to the provider's service, so the usual questions apply about what you send and what they retain.
• Missing credentials fail quietly in some clients — if no tools show up, check the environment block first.
• Keep per-call confirmation enabled while you learn its behaviour; it is the cheapest safeguard you have.

How it compares

This sits in the cloud and infrastructure group, where several servers overlap in what they claim to do but differ sharply once you actually set them up. Transitland's toolset — transitland_find_operators, transitland_get_operator, transitland_find_feeds and 5 more — is a fair guide to whether it matches your workflow. It is maintained by cyanheads; worth a glance at recent repository activity before you build anything load-bearing on it.

We check each listing at SyncDev against the project's documentation before it goes live — if something here drifts out of date, it is a bug worth reporting.