Tools

Six tools mirroring the Transitland resource hierarchy — operators → feeds → routes → stops → departures:

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, or adm0_name/adm1_name (country/region)
• Returns each operator's Onestop ID, name, the places it serves, the feeds it publishes (a GTFS_RT entry 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 after cursor; enrichment.totalCount and 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 (from transitland_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, or fetch_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
• authorizationRequired flags 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), or search
• Returns short/long name, the route's GTFS route_type mapped 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 after cursor

transitland_find_stops

Locate stops and stations — the step before departures.

• Filter by lat+lon+radius, bbox, onestop_id, or served_by_onestop_ids (operator/route network)
• Returns coordinates, GTFS location_type with 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_type 0) — 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_stops first
• Every departure carries a realtime flag — true for a live GTFS-Realtime prediction, false for a static scheduled time — plus a scheduleRelationship (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 realtimeAvailable reports whether the stop's feed publishes GTFS-RT at all
• Widen next_seconds (up to 24h) or set use_service_window: true when a stop returns nothing — some feeds only expose times inside their declared service window

Resources and prompts

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 realtime boolean and scheduleRelationship, plus a top-level realtimeAvailable, 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.next URL embeds the API key in plaintext; the service discards it and surfaces only the opaque integer after cursor, 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.4.0 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

1. Clone the repository:

git clone https://github.com/cyanheads/transitland-mcp-server.git

2. Navigate into the directory:

cd transitland-mcp-server

3. Install dependencies:

bun install

4. 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.

See .env.example for the full list of optional overrides.

Running the server

Local development

• Build and run:

  sh

  Copy

  # One-time build
  bun run rebuild
  
  # Run the built server
  bun run start:stdio
  # or
  bun run start:http
  

• Run checks and tests:

  sh

  Copy

  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

Development guide

See CLAUDE.md / AGENTS.md for development guidelines and architectural rules. The short version:

• Handlers throw, framework catches — no try/catch in tool logic
• Use ctx.log for request-scoped logging, ctx.state for 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.