@cyanheads/transitland-mcp-server

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

Category
Visit Server

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">

Version License Docker MCP SDK npm TypeScript Bun

</div>

<div align="center">

Install in Claude Desktop Install in Cursor Install in VS Code

Framework

</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, 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

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

Installation

  1. Clone the repository:
git clone https://github.com/cyanheads/transitland-mcp-server.git
  1. Navigate into the directory:
cd transitland-mcp-server
  1. Install dependencies:
bun install
  1. 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/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.

Recommended Servers

playwright-mcp

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.

Official
Featured
TypeScript
Magic Component Platform (MCP)

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.

Official
Featured
Local
TypeScript
Audiense Insights MCP Server

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.

Official
Featured
Local
TypeScript
VeyraX MCP

VeyraX MCP

Single MCP tool to connect all your favorite tools: Gmail, Calendar and 40 more.

Official
Featured
Local
Kagi MCP Server

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.

Official
Featured
Python
graphlit-mcp-server

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.

Official
Featured
TypeScript
Neon Database

Neon Database

MCP server for interacting with Neon Management API and databases

Official
Featured
Exa Search

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.

Official
Featured
Qdrant Server

Qdrant Server

This repository is an example of how to create a MCP server for Qdrant, a vector search engine.

Official
Featured
E2B

E2B

Using MCP to run code via e2b.

Official
Featured