Diese Seite ist ein echter MCP-Client, der im Browser läuft.
Er spricht rohes JSON-RPC über Streamable HTTP mit einem Cloudflare Worker, der den db-timetable-mcp-Server ausführt. Dazwischen liegt kein REST-Wrapper. Im Protokoll lässt sich jede Nachricht im Original lesen.
Der Worker ist zustandslos: jeder Aufruf steht für sich, es gibt keine Session-ID, und GET sowie DELETE werden mit 405 beantwortet.
Live-Tafel
Bahnhof suchen, dann die Abfahrten beobachten, die der Worker aus Sollfahrplan und Echtzeitänderungen zusammenführt.
Beispiele
Protokoll
Jede JSON-RPC-Nachricht, die diese Seite mit dem Worker ausgetauscht hat, in Reihenfolge. Zum Lesen der Bytes und ihrer Bedeutung aufklappen. Überlange Fahrplan-Antworten werden für den Browser gekürzt und als gekürzt markiert.
Werkzeuge, die der Server anbietet
Eine Suche holt `tools/list`.
Was ist MCP?
MCP, das Model Context Protocol, ist ein Weg für ein Programm, die Werkzeuge eines anderen aufzurufen, ohne dass beide wissen müssen, wie das jeweils andere gebaut ist. Diese Seite ist das eine Programm. Der Worker ist das andere.
Der Browser ruft hier fünf Werkzeuge namentlich auf und erhält strukturiertes JSON. Er sieht die Fahrplandaten der Deutschen Bahn. Er sieht nie, was der Server für sich behält.
Das ist der Sinn des Musters. Der Client fragt nach einem Ergebnis; alles andere bleibt beim Server.
Drei Fassungen desselben Moments
Ankunft und Abfahrt tragen bis zu drei Fassungen derselben Zeit. Genau diesen Teil verwerfen die meisten Anzeigen.
- planned
- Der ursprüngliche Sollfahrplan. Was der Betreiber fahren wollte.
- changed
- Nur die später gemeldeten Abweichungen. Unveränderte Felder fehlen schlicht.
- effective
- Der anzuzeigende Wert: die Änderung, wo es eine gibt, sonst der Sollwert. Ist ein Zug pünktlich, fehlt
changedundeffectivegleichtplanned. Dieses Fehlen ist die Aussage, keine Lücke.
Warum eine Tafel keinen Aufruf kostet
Eine einzelne Tafel braucht bis zu zwei Upstream-Anfragen. Zehn Besucher innerhalb von dreißig Sekunden brauchen weiterhin zwei. Der Worker cached die Upstream-Antworten, alle späteren lesen aus dem Cache.
Die Fenster sind 30 Sekunden für Live-Daten, eine Stunde für den Sollfahrplan und 24 Stunden für Stationsdaten.
Ist das DB-Kontingent erschöpft oder die API gestört, liefert der Worker bis zu sechs Stunden lang den letzten Stand und markiert ihn als veraltet. Eine alte Tafel ist besser als eine Fehlerseite, solange sie es sagt.
Die fünf Werkzeuge
Für eine Bahnhofstafel immer getStationBoard nehmen. Es führt Plan und Echtzeitänderungen in einem Aufruf zusammen.
- getStationBoard: die zusammengeführte Tafel für einen Bahnhof und eine Stunde. Für Zeiten und Gleise
effectiveverwenden. - getPlannedTimetable: der statische Sollfahrplan für Bahnhof, Tag und Stunde. Ohne Echtzeitänderungen.
- getCurrentTimetable: der vollständige Bestand bekannter Änderungen. Das sind Änderungsdaten, keine fertige Tafel.
- getRecentChanges: nur die Änderungen der letzten zwei Minuten. Ein Delta für häufige Aktualisierungen, keine Tafel für sich.
- findStations: Bahnhöfe nach Name, EVA-Nummer oder DS100-Code suchen.
Neben den Werkzeugen bietet der Server vier Resource-Templates: db-api:timetable/current/{evaNo}, db-api:timetable/changes/{evaNo}, db-api:timetable/planned/{evaNo}/{date}/{hour} und db-api:station/{pattern}.
Grenzen
Das DB-API-Kontingent des Betreibers ist persönlich und klein. Cache und Circuit Breaker halten eine gut besuchte Seite davon ab, es zu verbrennen.
| Ressource | Grenze | Verhalten |
|---|---|---|
| Live-Daten im Cache | 30 s | Ein Upstream-Aufruf pro Bahnhofstafel und Fenster, unabhängig von der Besucherzahl. |
| Sollfahrplan im Cache | 1 h | Fahrpläne für Bahnhof, Tag und Stunde sind innerhalb der Stunde statisch. |
| Stationsdaten im Cache | 24 h | Stationsdatensätze ändern sich praktisch nie. |
| Veraltet-Fenster | 6 h | Ist das Kontingent erschöpft, wird der letzte Stand ausgeliefert und als veraltet markiert. |
| Rate-Limit pro Besucher | 20 / min, 200 / h | HTTP 429 mit Retry-After. Best effort, nur im Speicher des Workers. |
| Circuit Breaker | 30 s | Nach einem Upstream-429 werden 30 s lang keine weiteren Upstream-Aufrufe versucht. |
Datenquelle und Namensnennung
Die Fahrplandaten stammen von der Deutschen Bahn über den DB API Marketplace und stehen unter der Creative Commons Attribution 4.0 International Lizenz (CC BY 4.0).
Enthält Fahrplandaten der Deutschen Bahn AG, lizenziert unter CC BY 4.0. Quelle: DB API Marketplace, Timetables API.
Die Namensnennung ist Lizenzbedingung, keine Höflichkeit. Diese Seite ist mit der Deutschen Bahn AG weder verbunden noch von ihr gebilligt.
Datenschutz
- Keine Cookies, keine Analytics, keine Tracking-Pixel, keine Drittanbieter-Anfragen. Alle Assets kommen von dieser Origin.
- Deine Bahnhofssuchen werden nicht gespeichert. Der Worker antwortet und vergisst.
- Der Worker nutzt deine IP-Adresse nur im Speicher, um Anfragen gegen das Rate-Limit zu zählen. Zähler werden nie gespeichert oder protokolliert.
- Der Worker protokolliert den abgerufenen Upstream-Pfad, etwa
/plan/8000105/260910/16, damit der Cache prüfbar ist. Er protokolliert weder deine IP noch den Inhalt deiner Anfragen. - Cloudflare und Vercel verarbeiten Anfragen als Hoster und können Betriebsprotokolle führen.