Veranstaltungsdaten per MCP-Server für KI-Assistenten öffnen
KI-generiert, menschlich reviewt
Ein Planetarium bekommt jeden Tag dieselben Fragen: Welche Vorstellung läuft am Sonntagnachmittag? Sind für die 15-Uhr-Kuppelshow noch Plätze frei? Ist der Saal barrierefrei erreichbar, und wie lang dauert das Programm? Die Antworten stehen nicht in den statischen Texten der Website — sie leben im Ticketing- und Veranstaltungssystem, wo sich der Belegungsstand im Minutentakt ändert. Wer heute einen KI-Assistenten auf die eigene Website oder ins Servicetelefon integrieren will, steht damit vor einem Problem: Das Sprachmodell kennt die Hausordnung, aber nicht den aktuellen Spielplan.
Der naheliegende Reflex — Veranstaltungsdaten regelmäßig exportieren und in den Prompt oder eine Wissensdatenbank kippen — löst das nur scheinbar. Ein Export ist in dem Moment veraltet, in dem er entsteht, und ein Assistent, der aus altem Stand eine längst ausverkaufte Show empfiehlt, richtet mehr Schaden an als eine ehrliche Nicht-Antwort. Dieser Artikel zeigt einen sauberen Weg: einen MCP-Server für Veranstaltungsdaten, der das Ticketing-Backend kontrolliert und in Echtzeit für KI-Assistenten erreichbar macht — ohne die Datenhoheit aus der Hand zu geben.
Warum Veranstaltungsdaten ein Sonderfall sind
Die meisten Inhalte eines Kulturbetriebs sind träge: die Anfahrtsbeschreibung, die Geschichte des Hauses, die Preiskategorien. Solches Wissen lässt sich einmal aufbereiten und ändert sich selten. Veranstaltungsdaten verhalten sich genau umgekehrt. Sie sind zeitkritisch und transaktional:
- Verfügbarkeit ändert sich mit jedem verkauften Ticket — eine Antwort von vor zehn Minuten kann schon falsch sein.
- Termine verschieben sich, Zusatzvorstellungen kommen dazu, einzelne Shows fallen aus.
- Saal- und Platzlogik ist bei einer Kuppel eigen: Sitzkategorien, Blickachsen, Liegesitze, barrierefreie Plätze — nicht jeder Platz ist gleichwertig.
Für einen KI-Assistenten heißt das: Er darf diese Daten nicht auswendig kennen, sondern muss sie im Moment der Frage abrufen. Genau das leistet ein statischer Export nicht. Und je näher eine Auskunft an einer Kaufentscheidung liegt, desto teurer wird ein Fehler — eine falsche Verfügbarkeitsangabe erzeugt Frust an der Kasse, nicht nur im Chatfenster.
Model Context Protocol (MCP): kurz eingeordnet
Das Model Context Protocol (MCP) ist ein offener Standard, über den KI-Assistenten mit externen Systemen sprechen. Statt Daten in den Prompt zu kopieren, stellt ein MCP-Server dem Modell klar umrissene Werkzeuge (Tools) bereit: benannte Funktionen mit typisiertem Eingabe- und Ausgabeschema. Das Modell entscheidet zur Laufzeit, welches Werkzeug es mit welchen Argumenten aufruft; die eigentliche Logik bleibt auf Ihrer Seite.
Der Gewinn ist Kontrolle. Sie legen fest, welche Fragen überhaupt beantwortbar sind, welche Daten das Modell sieht und welche nie. Wie ein solcher Server technisch entsteht, zeigt unser Leitfaden zum eigenen MCP-Server in TypeScript im Detail. Hier geht es um die Architektur-Entscheidung, die davor steht.
Die Architektur: ein MCP-Server für Veranstaltungsdaten
Der MCP-Server sitzt als schmale, eigenständige Schicht zwischen dem KI-Assistenten und dem Ticketing-Backend — etwa einem self-hosted System wie pretix. Der Assistent spricht nie direkt mit der Ticketing-Datenbank; er stellt ausschließlich die Werkzeuge zur Verfügung, die der Server anbietet.
flowchart LR
A[KI-Assistent] -->|Tool-Aufruf| B[MCP-Server]
B -->|geprüfte Abfrage| C[Ticketing-Backend]
C -->|Live-Daten| B
B -->|strukturierte Antwort| A
B -.->|Audit-Log| D[(Protokoll)]
Entscheidend ist der Zuschnitt der Werkzeuge. Nicht „gib mir die Datenbank”, sondern eng gefasste, lesende Abfragen, die genau die täglichen Fragen abdecken:
vorstellungen_finden(datum, zeitraum)— welche Shows laufen in einem Zeitfenster.verfuegbarkeit_pruefen(vorstellung_id)— freie Plätze je Sitzkategorie, live.vorstellung_details(vorstellung_id)— Dauer, Altersempfehlung, Barrierefreiheit, Sprache.
Werkzeuge statt Datenabzug
Dieser Zuschnitt ist kein Detail, sondern der Kern des Konzepts. Jedes Werkzeug ist eine bewusst gezogene Grenze. Es gibt kein Tool, das Rohdaten in Masse ausliefert, keinen Zugriff auf Bestell- oder Kundendaten, keine schreibende Operation. Der Assistent kann informieren und zum Kauf hinführen — den Kauf selbst löst weiterhin der reguläre, geprüfte Bestellprozess aus. So bleibt die Angriffsfläche klein und jede Antwort auf eine nachvollziehbare Abfrage zurückführbar.
Ein Ablauf, Schritt für Schritt
An einer einzigen Nutzerfrage lässt sich zeigen, warum diese Trennung trägt. Ein Gast fragt den Website-Assistenten: „Können wir Sonntag mit zwei Kindern in eine Nachmittagsshow, und ist die barrierefrei?” Der Assistent zerlegt das in zwei Schritte. Zuerst ruft er vorstellungen_finden mit dem Datum und dem Zeitfenster „Nachmittag” auf und erhält die passenden Shows. Für die konkrete Vorstellung fragt er dann vorstellung_details (Altersempfehlung, Barrierefreiheit) und verfuegbarkeit_pruefen (freie Plätze in den relevanten Kategorien) ab.
Erst mit diesen drei geprüften Antworten formuliert das Modell seine Auskunft — samt ehrlichem „für 15 Uhr ist nur noch die hintere Reihe frei, 17 Uhr ist offen”. Nichts davon stammt aus dem Gedächtnis des Modells; jede Zahl ist der Rückgabewert eines protokollierten Tool-Aufrufs. Fällt eine Abfrage aus, weil das Backend gerade nicht erreichbar ist, sagt der Assistent das — statt eine plausible, aber erfundene Antwort zu liefern.
Warum nicht einfach RAG oder ein Export?
Ein berechtigter Einwand: Für das Wissen eines Hauses setzt man doch üblicherweise Retrieval-Augmented Generation (RAG) ein — Dokumente werden eingebettet und zur Laufzeit nach Ähnlichkeit abgerufen. Das stimmt, aber RAG und MCP lösen verschiedene Probleme. RAG ist stark bei umfangreichem, relativ stabilem Textwissen; die Wahl des passenden Vektor-Stores dafür behandeln wir in Qdrant oder pgvector für self-hosted RAG. Für minütlich wechselnde Verfügbarkeiten ist es das falsche Werkzeug.
| Kriterium | RAG (Wissensbasis) | MCP-Server (Fachsystem) |
|---|---|---|
| Datencharakter | träge, textlastig | live, transaktional |
| Aktualität | Stand des letzten Ingest | Echtzeit bei jeder Abfrage |
| Typische Frage | „Wie ist die Hausordnung?” | „Sind um 15 Uhr noch Plätze frei?” |
| Fehlerbild | veraltete Textpassage | falsche Zahl an der Kasse |
In der Praxis ergänzen sich beide: RAG beantwortet Fragen zu Hausordnung, Anfahrt und Programmbeschreibungen; der MCP-Server liefert den Live-Teil. Derselbe Assistent nutzt für dieselbe Nutzeranfrage beide Quellen — je nachdem, ob die Antwort im Text oder im Fachsystem steht.
Sicherheit und Datenhoheit
Ein Fachsystem für eine KI zu öffnen, klingt zunächst nach einem Risiko. Genau deshalb gehört die Absicherung ins Zentrum des Entwurfs, nicht ans Ende:
- Self-hosted by default. Der MCP-Server läuft auf Ihrer Infrastruktur, neben dem Ticketing-Backend. Veranstaltungs- und erst recht Kundendaten verlassen Ihr Haus nicht.
- AuthN/AuthZ. Zugriffe werden authentifiziert und autorisiert — etwa über OAuth 2.1, angebunden an ein bestehendes Single Sign-on mit Keycloak. Ein öffentlicher Website-Assistent bekommt andere Rechte als ein interner.
- Nur lesend, eng gescopt. Die Werkzeuge decken exakt die vorgesehenen Fragen ab. Was nicht als Tool existiert, ist nicht abfragbar.
- Rate-Limiting und Audit-Log. Jeder Tool-Aufruf wird protokolliert und begrenzt. So bleibt nachvollziehbar, wer wann welche Daten gesehen hat — Auditierbarkeit vor Magie.
Personenbezogene Bestelldaten haben in diesem Entwurf bewusst keinen Platz. Der Assistent arbeitet mit Spielplan und Verfügbarkeit, nicht mit den Buchungen einzelner Gäste.
Betrieb: was nach dem Prototyp bleibt
Ein MCP-Server ist schnell als Demo gebaut. Der Unterschied zeigt sich im Betrieb. Das Werkzeug-Schema ist eine Schnittstelle und muss versioniert werden, damit Änderungen die angebundenen Assistenten nicht überraschen. Verfügbarkeiten lassen sich mit einer kurzen Cache-Lebensdauer abfedern, ohne die Aktualität zu verlieren — ein Kompromiss, den man bewusst wählt und dokumentiert. Und wenn das Ticketing-Backend seine API ändert, darf das nicht bis zum Assistenten durchschlagen; der Server kapselt diese Abhängigkeit.
Ebenso gehört die Beobachtbarkeit zum Betrieb: Welche Werkzeuge werden wie oft aufgerufen, wo laufen Abfragen in Fehler, welche Fragen kann der Assistent gar nicht beantworten? Diese Signale zeigen, wo ein Werkzeug fehlt oder zu grob geschnitten ist — der MCP-Server wächst mit den realen Fragen der Gäste, statt auf einem Reißbrettstand einzufrieren.
Genau hier liegt die Linie, an der Kontrollfeld arbeitet: Wir bauen und betreiben solche MCP-Server als eigenständige, überwachte Dienste — mit Monitoring, versioniertem Schema und dokumentierten Entscheidungen, nicht als einmaligen Prototyp.
Fazit
- Veranstaltungsdaten sind live und transaktional — ein statischer Export oder eine reine Wissensbasis bildet sie nicht korrekt ab.
- Ein MCP-Server für Veranstaltungsdaten öffnet das Ticketing-Backend über eng gefasste, lesende Werkzeuge — kontrolliert statt per Datenabzug.
- RAG und MCP schließen sich nicht aus: RAG für träges Textwissen, MCP für den Echtzeit-Teil.
- Sicherheit und Datenhoheit entstehen durch Self-Hosting, Scoping, Authentifizierung und ein Audit-Log — nicht durch nachträgliche Härtung.
Wenn Sie ein Ticketing- oder Fachsystem kontrolliert für KI-Assistenten öffnen wollen, ohne die Kontrolle darüber abzugeben: So gehen wir bei MCP-Servern vor.