Unofficial MCP Server for Berliner Verkehrsbetriebe API

Overview

This project provides an unofficial MCP (Model Context Protocol) server that wraps the Berliner Verkehrsbetriebe (BVG) transit data and exposes it through a small set of simple HTTP endpoints. The server acts as a lightweight adapter between BVG’s data sources and applications or language models that consume structured context. Instead of integrating directly with the raw BVG APIs, you can query this MCP server for ready-to-use JSON fragments that are optimised for embedding in prompts, dashboards, or developer tools.

The server is useful when you need near real-time transit information (stops, departures, vehicle locations, and service disruptions) in a predictable, model-friendly format. It’s designed for developers who want to add BVG transit context to chatbots, mobile apps, or monitoring dashboards without handling the full complexity of the underlying BVG endpoints.

Features

• Exposes BVG transit data through a small set of MCP-style HTTP endpoints
• Returns consistent, model-friendly JSON context fragments
• Caching and rate-limiting helpers (where applicable) to reduce upstream load
• Docker-friendly and easy to run locally for dev/testing
• Configurable upstream BVG endpoint and API keys via environment variables
• Simple, documented endpoints for stops, departures, vehicles, lines and disruptions

Installation / Configuration

Clone the repository and run locally (Node.js example):

git clone https://github.com/svkaizoku/mcp-bvg.git
cd mcp-bvg
npm install
cp .env.example .env
# Edit .env to include any required API keys or config
npm start

Docker (build and run):

# Build image
docker build -t mcp-bvg .

# Run container (default port 3000)
docker run -p 3000:3000 \
  -e BVG_API_KEY="your_key_here" \
  -e PORT=3000 \
  mcp-bvg

Typical environment variables (adjust names to match the repo configuration):

• PORT — HTTP port the server listens on (default 3000)
• BVG_API_URL — upstream BVG API base URL (if applicable)
• BVG_API_KEY — API key or token for BVG data (if required)
• CACHE_TTL — optional cache time-to-live for upstream responses

Example .env snippet:

PORT=3000
BVG_API_URL=https://api.bvg.de
BVG_API_KEY=changeme
CACHE_TTL=30

After starting, the server will be available at http://localhost:3000 (or your configured PORT).

Available Resources

• Source code and issues: https://github.com/svkaizoku/mcp-bvg
• BVG / public transport documentation: consult BVG or Berlin public transport open-data pages for upstream API details
• MCP spec and integrations: check your Model Context Protocol implementation docs if you are integrating this server with LLM tooling

Common endpoints exposed by the MCP server (implementation-dependent — check the repo for exact paths):

Responses are JSON objects formatted to be easy to concatenate into model context blocks (short summaries, timestamps, and structured lists).

Use Cases

• Chatbot assistant: supply up-to-date departure lists and disruption info to a conversational agent that answers “When is the next U-Bahn from Alexanderplatz?”

  • Example curl call:

    curl "http://localhost:3000/mcp/bvg/departures?stopId=900000100101"
    

    Expected response shape (example):

    {
      "stopId": "900000100101",
      "stopName": "Alexanderplatz",
      "departures": [
        {"line": "U2", "direction": "Ruhleben", "inMin": 3, "platform": "Gleis 1"},
        {"line": "U5", "direction": "Hönow", "inMin": 5, "platform": "Gleis 2"}
      ],
      "fetchedAt": "2026-04-10T08:12:34Z"
    }
    

• Mobile or web apps: embed a small backend call to present arrival times, vehicle locations, or disruption notices without exposing BVG credentials to the client.

• LLM context provider: feed structured, recent transit context into a language model prompt for routing advice or trip planning.

• Monitoring dashboards: poll the MCP server for disruptions and surface alerts in operational views.

Notes and Best Practices

• This server is an unofficial wrapper around BVG data. Verify upstream terms of use and rate limits before deploying to production.
• Use caching and rate limiting (both client-side and server-side) to avoid hitting upstream BVG limits.
• Validate the endpoints and environment variable names against the repository’s README or source code before deploying — different commits may change configuration keys or paths.

For full implementation details, supported endpoints and configuration options, see the project repository: https://github.com/svkaizoku/mcp-bvg.