Opening event data to AI assistants via an MCP server
AI-generated, human-reviewed
A planetarium fields the same questions every day: What show runs on Sunday afternoon? Are seats still available for the 3 p.m. dome show? Is the auditorium wheelchair-accessible, and how long is the programme? The answers aren’t in the website’s static copy — they live in the ticketing and event system, where availability shifts by the minute. Anyone integrating an AI assistant into their website or service line runs into the same wall: the model knows the house rules, but not today’s schedule.
The obvious reflex — export event data on a schedule and drop it into the prompt or a knowledge base — only appears to solve this. An export is stale the moment it’s created, and an assistant that recommends a long-sold-out show from an old snapshot does more harm than an honest non-answer. This article shows a cleaner path: an MCP server for event data that exposes the ticketing backend in real time, under control, without giving up data sovereignty.
Why event data is a special case
Most of a cultural venue’s content is slow-moving: directions, the building’s history, price tiers. That kind of knowledge is prepared once and rarely changes. Event data behaves the opposite way. It is time-critical and transactional:
- Availability changes with every ticket sold — an answer from ten minutes ago may already be wrong.
- Dates shift, extra showings appear, individual shows get cancelled.
- Seating logic is peculiar in a dome: seat categories, sightlines, reclined seats, accessible spaces — not every seat is equivalent.
For an AI assistant this means it must not know these facts by heart; it has to retrieve them at the moment of the question. A static export cannot do that. And the closer an answer sits to a purchase decision, the more expensive a mistake becomes — a wrong availability claim causes friction at the box office, not just in a chat window.
Model Context Protocol (MCP): a quick framing
The Model Context Protocol (MCP) is an open standard through which AI assistants talk to external systems. Instead of copying data into the prompt, an MCP server offers the model clearly bounded tools: named functions with typed input and output schemas. The model decides at runtime which tool to call with which arguments; the actual logic stays on your side.
The payoff is control. You define which questions are answerable at all, which data the model sees, and which it never does. How such a server is built in practice is covered in our guide to building your own MCP server in TypeScript. Here we focus on the architectural decision that comes first.
The architecture: an MCP server for event data
The MCP server sits as a thin, standalone layer between the AI assistant and the ticketing backend — for example a self-hosted system like pretix. The assistant never talks to the ticketing database directly; it only ever uses the tools the server exposes.
flowchart LR
A[AI assistant] -->|tool call| B[MCP server]
B -->|checked query| C[Ticketing backend]
C -->|live data| B
B -->|structured response| A
B -.->|audit log| D[(Log)]
What matters is how the tools are cut. Not “hand me the database”, but narrow, read-only queries that cover exactly the everyday questions:
find_showings(date, window)— which shows run in a time window.check_availability(showing_id)— free seats per category, live.showing_details(showing_id)— duration, age guidance, accessibility, language.
Tools, not a data dump
This framing isn’t a detail — it’s the heart of the concept. Every tool is a deliberately drawn boundary. There is no tool that hands out raw data in bulk, no access to order or customer data, no write operation. The assistant can inform and guide toward a purchase — the purchase itself still runs through the regular, verified checkout. That keeps the attack surface small and every answer traceable to an auditable query.
A step-by-step flow
A single user question shows why the separation holds. A guest asks the website assistant: “Can we take two kids to an afternoon show on Sunday, and is it accessible?” The assistant breaks this into steps. First it calls find_showings with the date and the “afternoon” window and gets the matching shows. For the specific showing it then queries showing_details (age guidance, accessibility) and check_availability (free seats in the relevant categories).
Only with these three checked answers does the model phrase its reply — including an honest “3 p.m. only has the back row left, 5 p.m. is open”. None of it comes from the model’s memory; every number is the return value of a logged tool call. If a query fails because the backend is briefly unreachable, the assistant says so — rather than inventing a plausible answer.
Why not just RAG or an export?
A fair objection: for a venue’s knowledge you would normally reach for Retrieval-Augmented Generation (RAG) — documents are embedded and retrieved by similarity at runtime. True, but RAG and MCP solve different problems. RAG is strong with large, fairly stable bodies of text; choosing the right vector store for it is covered in Qdrant vs. pgvector for self-hosted RAG. For availability that changes by the minute, it is the wrong tool.
| Criterion | RAG (knowledge base) | MCP server (domain system) |
|---|---|---|
| Data character | slow, text-heavy | live, transactional |
| Freshness | state of last ingest | real time on every query |
| Typical question | ”What are the house rules?" | "Any seats left at 3 p.m.?” |
| Failure mode | stale passage | wrong number at the box office |
In practice the two complement each other: RAG answers questions on house rules, directions and programme descriptions; the MCP server delivers the live part. The same assistant uses both sources for the same user query — depending on whether the answer lives in text or in the domain system.
Security and data sovereignty
Opening a domain system to an AI sounds like a risk at first. That is precisely why protection belongs at the centre of the design, not at the end:
- Self-hosted by default. The MCP server runs on your infrastructure, next to the ticketing backend. Event data — and customer data all the more so — never leaves your house.
- AuthN/AuthZ. Access is authenticated and authorised — for example via OAuth 2.1, tied into an existing Single Sign-on with Keycloak. A public website assistant gets different rights than an internal one.
- Read-only, tightly scoped. The tools cover exactly the intended questions. What isn’t a tool isn’t queryable.
- Rate limiting and an audit log. Every tool call is logged and bounded. It stays traceable who saw which data when — auditability over magic.
Personal order data has no place in this design by intent. The assistant works with schedule and availability, not with individual guests’ bookings.
Operations: what survives the prototype
An MCP server is quick to build as a demo. The difference shows up in operations. The tool schema is an interface and must be versioned, so changes don’t surprise the connected assistants. Availability can be cushioned with a short cache lifetime without losing freshness — a trade-off you choose and document deliberately. And when the ticketing backend changes its API, that must not ripple through to the assistant; the server encapsulates the dependency.
Observability belongs to operations too: which tools get called how often, where do queries error out, which questions can the assistant not answer at all? These signals reveal where a tool is missing or cut too coarsely — the MCP server grows with guests’ real questions instead of freezing at a drawing-board state.
This is exactly the line Kontrollfeld works on: we build and operate such MCP servers as standalone, monitored services — with monitoring, a versioned schema and documented decisions, not as a one-off prototype.
Takeaways
- Event data is live and transactional — a static export or a plain knowledge base won’t represent it correctly.
- An MCP server for event data exposes the ticketing backend through narrow, read-only tools — controlled, not by data dump.
- RAG and MCP aren’t mutually exclusive: RAG for slow text knowledge, MCP for the real-time part.
- Security and data sovereignty come from self-hosting, scoping, authentication and an audit log — not from hardening bolted on afterwards.
If you want to open a ticketing or domain system to AI assistants in a controlled way, without giving up control over it: this is how we approach MCP servers.