MCP im Data Warehouse: Agenten brauchen einen Semantic Layer, kein SQL

Das Model Context Protocol beschreibt, wie ein Modell Werkzeuge und Datenquellen entdeckt und aufruft. Für ein Data Warehouse ist das verlockend einfach umzusetzen: ein Werkzeug, das SQL annimmt, eine Verbindung, fertig. In der Praxis entstehen daraus drei Probleme, die alle dieselbe Wurzel haben – das Modell bekommt zu viel Freiheit an der falschen Stelle.

Problem eins: das Schema ist keine Semantik

Ein Warehouse-Schema beschreibt, wie Daten liegen, nicht was sie bedeuten. In einer typischen Umgebung existieren mehrere Tabellen, die plausibel nach Umsatz aussehen: eine aus der Vorsystem-Replikation, eine mit Storno-Bereinigung, eine mit Konzernwährungsumrechnung. Alle drei haben eine Spalte, die sich betrag nennt.

Ein Modell, das nur das Schema kennt, wählt danach, was am besten passt – nach Namensähnlichkeit. Es hat keine Möglichkeit zu wissen, dass die Controlling-Kennzahl aus der dritten Tabelle kommt, dass Stornos abzuziehen sind und dass die Fremdwährungsumrechnung zum Monatsendkurs erfolgt. Die Antwort ist syntaktisch gültiges SQL, das eine Zahl liefert. Nur nicht die Zahl, die im Bericht steht.

Der Fehler ist nicht, dass das Modell schlecht rät. Der Fehler ist, dass man es raten lässt.

Problem zwei: Rechte gelten pro Anfrage, nicht pro Verbindung

Ein MCP-Server läuft als Prozess und hält typischerweise eine Verbindung zum Warehouse. Wenn diese Verbindung unter einem technischen Nutzer aufgebaut wird, sieht jeder Agent alles, was dieser Nutzer sehen darf – unabhängig davon, in wessen Auftrag er fragt. Zeilenfilter und Spaltenmaskierung, die für Menschen sorgfältig eingerichtet wurden, sind damit umgangen.

Richtig ist der umgekehrte Weg: die Identität des Anfragenden wird bis in die Datenbanksitzung durchgereicht, und die Rechteprüfung passiert dort, wo sie für Menschen auch passiert. Technisch heißt das Token-Weitergabe über OIDC und eine Sitzung pro Anfrage statt einer geteilten Verbindung.

# Falsch: eine Verbindung, ein technischer Nutzer
connection:
  user: svc_mcp
  role: analytics_all

# Richtig: Identität pro Anfrage, Rolle folgt dem Anfragenden
auth:
  mode: oidc_token_passthrough
  session: per_request
  fallback_role: none        # kein stiller Rückfall auf mehr Rechte

Der fallback_role: none ist der wichtigste Teil. Ein Rückfall auf eine Standardrolle wirkt betriebsfreundlich und hebt im Fehlerfall genau die Grenze auf, die man ziehen wollte.

Problem drei: freies SQL ist nicht auditierbar

Ein Audit-Log, das beliebige SQL-Texte enthält, ist ein Archiv, keine Prüfgrundlage. Auf die Frage einer Revision, ob ein Agent auf Personaldaten zugegriffen hat, muss man tausende Abfragen parsen. Bei einem Semantic Layer lautet der Log-Eintrag stattdessen: Metrik, Dimension, Filter, Rolle, Zeitpunkt – und die Frage ist mit einer Abfrage beantwortet.

Wie die Schnittstelle stattdessen aussieht

Ein MCP-Server für ein Warehouse sollte nicht ein Werkzeug anbieten, sondern mehrere abgestufte – von grob nach fein:

1. 1list_metrics – welche geprüften Kennzahlen gibt es, mit Beschreibung und erlaubten Dimensionen. Das ist der Katalog, aus dem das Modell wählt.
2. 2describe_metric – wie ist eine Kennzahl definiert, welche Filter gehören dazu, wer hat sie freigegeben. Damit kann das Modell seine Auswahl begründen.
3. 3query_metric – Kennzahl plus Dimensionen plus Filter. Das Warehouse erzeugt das SQL, nicht das Modell.
4. 4run_sql – als letzte Stufe, mit eigener Rolle, engem Zeitlimit und ausdrücklicher Freigabe. Für Fälle, die der Semantic Layer nicht abdeckt.

Der Unterschied ist nicht kosmetisch. In der ersten Variante beantwortet das Modell die Frage „welche Tabelle meint der Nutzer“. In der zweiten beantwortet sie der Semantic Layer, und das Modell beantwortet nur noch „welche Kennzahl ist gefragt“. Das ist die Aufgabe, für die es taugt.

Was das für Text-to-SQL bedeutet

Text-to-SQL wird gern als Fähigkeit des Modells diskutiert. Der begrenzende Faktor ist aber selten das Modell, sondern die Frage, ob es überhaupt eine eindeutige richtige Antwort geben kann. Wo drei Umsatztabellen existieren und keine als maßgeblich markiert ist, ist die Frage unterbestimmt – kein Modell kann sie zuverlässig lösen.

Wer Text-to-SQL verbessern will, arbeitet deshalb meist nicht am Prompt, sondern an den Metrikdefinitionen. Das ist unspektakulärere Arbeit und wirkt stärker.

Kurzfassung

Ein Agent, der sagt „diese Kennzahl steht mir nicht zur Verfügung“, ist unangenehmer als einer, der immer antwortet. Er ist aber der einzige, dessen Antworten man in einen Bericht übernehmen kann.