@cyanheads/transitland-mcp-server
Global transit data via the Transitland v2 registry — operators, GTFS/GTFS-RT/GBFS feeds with license terms, routes, stops, and real-time-aware departures via MCP.
README
<div align="center"> <h1>@cyanheads/transitland-mcp-server</h1> <p><b>Global transit data via the Transitland v2 registry — operators, GTFS/GTFS-RT/GBFS feeds with license terms, routes, stops, and real-time-aware departures via MCP. STDIO or Streamable HTTP.</b> <div>6 Tools • 2 Resources</div> </p> </div>
<div align="center">
</div>
<div align="center">
</div>
Tools
Six tools mirroring the Transitland resource hierarchy — operators → feeds → routes → stops → departures:
| Tool | Description |
|---|---|
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, and on what terms |
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 |
Transitland does not geocode place names. Turn a city or address into coordinates with a geocoding MCP server (e.g. openstreetmap-mcp-server's openstreetmap_geocode) first, then pass lat/lon or a bbox. Geocoding is intentionally not built in — this server resolves coordinates to transit, not names to coordinates.
transitland_find_operators
Find operators near a place or by name — the entry point that resolves a location to the agencies serving it.
- Filter by
search(operator/agency name),lat+lon+radius,bbox,onestop_id, oradm0_name/adm1_name(country/region) - Returns each operator's Onestop ID, name, the places it serves, the feeds it publishes (a
GTFS_RTentry signals real-time departures may be available), and its Wikidata QID for cross-referencing - At least one filter required — an unfiltered query is rejected with a recovery hint rather than returning a global dump
- Pagination via the
aftercursor;enrichment.totalCountand a truncation notice report capped results
transitland_get_operator
Fetch the complete operator record when you already hold an ID — no search round-trip.
- Accepts an Onestop ID (
o-9q9-bart) or an internal integer ID - Returns agencies (each with the places it serves), published feeds, and source tags: Wikidata QID, US NTD ID, and general social handle
- Idempotent single-record lookup; mirrored by the
transitland://operator/{onestop_id}resource
transitland_find_feeds
The open-data catalog — where to get a place's transit data and whether you may redistribute it.
- Pass
operator_onestop_id(fromtransitland_find_operators) to list exactly the feeds an operator publishes — the reliable path to a specific agency's feeds - Also filter by
spec(gtfs,gtfs-rt,gbfs,mds),search, orfetch_error(data-quality auditing) - Each feed returns its fetch URL, real-time endpoints when present, and license terms — redistribution, commercial use, derived products, and attribution as explicit
yes/no/unknown(never inferred from a blank registry field), plus SPDX identifier and attribution text where known - Freshness: last-fetch timestamp, content hash, and the calendar window the current data covers
authorizationRequiredflags feeds whose download needs a separate key/registration
transitland_find_routes
Find scheduled (GTFS static) route definitions by geography, operator, or mode.
- Filter by
lat+lon+radius,bbox,operator_onestop_id,onestop_id,route_type(GTFS mode), orsearch - Returns short/long name, the route's GTFS
route_typemapped to a human-readable mode (bus, subway, rail, ferry, tram, …), brand color, the operating agency's Onestop ID, and the source feed's Onestop ID - These are route definitions, not live vehicle positions
- At least one filter required; pagination via the
aftercursor
transitland_find_stops
Locate stops and stations — the step before departures.
- Filter by
lat+lon+radius,bbox,onestop_id, orserved_by_onestop_ids(operator/route network) - Returns coordinates, GTFS
location_typewith a label (stop, station, entrance, node, boarding area), wheelchair accessibility, timezone, and the parent station's Onestop ID for child platforms - Departures attach to platform-level stops (
location_type0) — a station may return none; use its child platforms - Pass a returned stop Onestop ID to
transitland_get_departures
transitland_get_departures
Departures from a stop, with the live-vs-scheduled distinction made structural.
- Resolve a stop to its Onestop ID with
transitland_find_stopsfirst - Every departure carries a
realtimeflag —truefor a live GTFS-Realtime prediction,falsefor a static scheduled time — plus ascheduleRelationship(STATIC,SCHEDULED,ADDED,CANCELED,UNSCHEDULED,DUPLICATED) so a timetable entry is never mistaken for a live arrival and cancellations are visible - Returns scheduled and (when real-time) estimated times with delay in seconds, route, headsign, mode, trip, direction, and accessibility
- Top-level
realtimeAvailablereports whether the stop's feed publishes GTFS-RT at all - Widen
next_seconds(up to 24h) or setuse_service_window: truewhen a stop returns nothing — some feeds only expose times inside their declared service window
Resources and prompts
| Type | Name | Description |
|---|---|---|
| Resource | transitland://operator/{onestop_id} |
Operator record by Onestop ID — agencies, places served, published feeds, and source tags. Mirrors transitland_get_operator. |
| Resource | transitland://feed/{onestop_id} |
Feed record by Onestop ID — spec, fetch URL, license terms, and latest-fetch freshness. The open-data catalog entry for one feed. |
All resource data is also reachable via tools (transitland_get_operator, transitland_find_feeds), so tool-only clients lose nothing. Stops and routes have no resource — they're discovered in bulk by geography, not referenced by a single stable URI. No prompts: the domain is operational data lookup, with workflow guidance carried in the tool descriptions (geocode-first, operator-then-feeds, stop-then-departures).
Features
Built on @cyanheads/mcp-ts-core:
- 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
Transitland-specific:
- Direct HTTP client for the Transitland v2 REST API — no SDK dependency, a flat query-param contract over a handful of GET endpoints
- Onestop IDs (
o-/f-/r-/s-) are the identifier spine — surfaced in every result, accepted on input alongside internal integer IDs - Feed-version history sliced to the latest version (the raw endpoint returns the entire fetch log — 167 entries for BART), so a feed lookup returns current freshness, not a multi-year history
- Coverage polygons and route/stop geometry omitted by default — a compact country/region/city place summary instead
Agent-friendly output:
- The real-time distinction is structural — a per-departure
realtimeboolean andscheduleRelationship, plus a top-levelrealtimeAvailable, so an agent branches on data, never on parsing a timestamp - License terms surfaced honestly — blank registry fields normalize to
unknown/null and are never inferred as permissive; the schema descriptions tell agents to confirm against the license URL before redistributing - The pagination
meta.nextURL embeds the API key in plaintext; the service discards it and surfaces only the opaque integeraftercursor, so the key never reaches tool output or logs - Empty results return data plus an actionable notice (geocode-first, widen the window, try a child platform) rather than an error
Getting started
Add the following to your MCP client configuration file. A Transitland API key is required — see Prerequisites for how to get one.
{
"mcpServers": {
"transitland-mcp-server": {
"type": "stdio",
"command": "bunx",
"args": ["@cyanheads/transitland-mcp-server@latest"],
"env": {
"MCP_TRANSPORT_TYPE": "stdio",
"MCP_LOG_LEVEL": "info",
"TRANSITLAND_API_KEY": "your-api-key"
}
}
}
}
Or with npx (no Bun required):
{
"mcpServers": {
"transitland-mcp-server": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@cyanheads/transitland-mcp-server@latest"],
"env": {
"MCP_TRANSPORT_TYPE": "stdio",
"MCP_LOG_LEVEL": "info",
"TRANSITLAND_API_KEY": "your-api-key"
}
}
}
}
Or with Docker:
{
"mcpServers": {
"transitland-mcp-server": {
"type": "stdio",
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "MCP_TRANSPORT_TYPE=stdio",
"-e", "TRANSITLAND_API_KEY=your-api-key",
"ghcr.io/cyanheads/transitland-mcp-server:latest"
]
}
}
}
For Streamable HTTP, set the transport and start the server:
MCP_TRANSPORT_TYPE=http MCP_HTTP_PORT=3010 TRANSITLAND_API_KEY=your-api-key bun run start:http
# Server listens at http://localhost:3010/mcp
Prerequisites
- 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.
Installation
- Clone the repository:
git clone https://github.com/cyanheads/transitland-mcp-server.git
- Navigate into the directory:
cd transitland-mcp-server
- Install dependencies:
bun install
- Configure environment:
cp .env.example .env
# edit .env and set TRANSITLAND_API_KEY
Configuration
All configuration is validated at startup via Zod schemas in src/config/server-config.ts. A missing TRANSITLAND_API_KEY fails at startup with a banner naming the variable, not at the first tool call.
| Variable | Description | Default |
|---|---|---|
TRANSITLAND_API_KEY |
Required. Transitland v2 API key, sent as the apikey query parameter. |
— |
TRANSITLAND_BASE_URL |
Transitland REST API base URL. Override to pin a specific deployment or a self-hosted instance. | https://transit.land/api/v2/rest |
MCP_TRANSPORT_TYPE |
Transport: stdio or http. |
stdio |
MCP_HTTP_PORT |
Port for the HTTP server. | 3010 |
MCP_HTTP_ENDPOINT_PATH |
HTTP endpoint path where the MCP server is mounted. | /mcp |
MCP_AUTH_MODE |
Authentication mode: none, jwt, or oauth. |
none |
MCP_LOG_LEVEL |
Log level (debug, info, notice, warning, error). |
info |
LOGS_DIR |
Directory for log files (Node.js only). | <project-root>/logs |
STORAGE_PROVIDER_TYPE |
Storage backend: in-memory, filesystem, supabase, cloudflare-kv/r2/d1. |
in-memory |
OTEL_ENABLED |
Enable OpenTelemetry instrumentation (spans, metrics, completion logs). | false |
See .env.example for the full list of optional overrides.
Running the server
Local development
-
Build and run:
# One-time build bun run rebuild # Run the built server bun run start:stdio # or bun run start:http -
Run checks and tests:
bun run devcheck # Lint, format, typecheck, security, changelog sync bun run test # Vitest test suite bun run lint:mcp # Validate MCP definitions against spec
Docker
docker build -t transitland-mcp-server .
docker run --rm -e TRANSITLAND_API_KEY=your-key -p 3010:3010 transitland-mcp-server
The Dockerfile defaults to HTTP transport, stateless session mode, and logs to /var/log/transitland-mcp-server. OpenTelemetry peer dependencies are installed by default — build with --build-arg OTEL_ENABLED=false to omit them.
Project structure
| Directory | Purpose |
|---|---|
src/index.ts |
createApp() entry point — registers tools and resources, inits the Transitland service. |
src/config |
Server-specific environment variable parsing and validation with Zod. |
src/mcp-server/tools |
Tool definitions (*.tool.ts). Six tools across operators, feeds, routes, stops, and departures. |
src/mcp-server/resources |
Resource definitions (*.resource.ts). Operator and feed records. |
src/services/transitland |
Transitland v2 REST client — HTTP, apikey injection, cursor normalization, error classification, and per-endpoint typed methods. |
tests/ |
Unit and integration tests mirroring src/. |
Development guide
See CLAUDE.md / AGENTS.md for development guidelines and architectural rules. The short version:
- Handlers throw, framework catches — no
try/catchin tool logic - Use
ctx.logfor request-scoped logging,ctx.statefor tenant-scoped storage - Register new tools and resources via the barrels in
src/mcp-server/*/definitions/index.ts - Wrap the Transitland API: validate raw → normalize to domain type → return output schema; never fabricate missing fields (especially license terms — blanks are
unknown, not permissive)
Contributing
Issues and pull requests are welcome. Run checks and tests before submitting:
bun run devcheck
bun run test
License
Apache-2.0 — see LICENSE for details.
Data & licensing
Transit data is provided by Transitland — an open registry aggregating GTFS, GTFS-Realtime, and GBFS feeds from thousands of operators worldwide. Products built on Transitland data must display the name "Transitland" with a link to transit.land/terms, clearly visible to end users.
Transitland aggregates feeds from thousands of operators, each of which may carry its own license and attribution requirements. Review the per-feed license terms at transit.land/terms and comply with each source feed's requirements before redistributing or publishing data obtained through this server.
Recommended Servers
playwright-mcp
A Model Context Protocol server that enables LLMs to interact with web pages through structured accessibility snapshots without requiring vision models or screenshots.
Magic Component Platform (MCP)
An AI-powered tool that generates modern UI components from natural language descriptions, integrating with popular IDEs to streamline UI development workflow.
Audiense Insights MCP Server
Enables interaction with Audiense Insights accounts via the Model Context Protocol, facilitating the extraction and analysis of marketing insights and audience data including demographics, behavior, and influencer engagement.
VeyraX MCP
Single MCP tool to connect all your favorite tools: Gmail, Calendar and 40 more.
Kagi MCP Server
An MCP server that integrates Kagi search capabilities with Claude AI, enabling Claude to perform real-time web searches when answering questions that require up-to-date information.
graphlit-mcp-server
The Model Context Protocol (MCP) Server enables integration between MCP clients and the Graphlit service. Ingest anything from Slack to Gmail to podcast feeds, in addition to web crawling, into a Graphlit project - and then retrieve relevant contents from the MCP client.
Neon Database
MCP server for interacting with Neon Management API and databases
Exa Search
A Model Context Protocol (MCP) server lets AI assistants like Claude use the Exa AI Search API for web searches. This setup allows AI models to get real-time web information in a safe and controlled way.
Qdrant Server
This repository is an example of how to create a MCP server for Qdrant, a vector search engine.
E2B
Using MCP to run code via e2b.