MCP erklärt: Wie KI-Agenten an Power BI, SQL und Excel andocken.

Eine Anfrage läuft in fünf Schritten. Der Nutzer stellt dem Agenten eine Aufgabe („Dokumentiere alle Measures der Tabelle Umsatz“). Der Agent fragt den MCP-Server, welche Werkzeuge es gibt, und wählt „Measures auflisten“. Der Server führt den Aufruf gegen das Semantikmodell aus — lesend, nur Metadaten — und gibt die Liste zurück. Das Modell formuliert die Dokumentation. Soll etwas geschrieben werden, läuft der Vorschlag vor dem Einspielen durch die Regelprüfung und die Freigabe.

Der entscheidende Punkt ist der Rückkanal: Nicht das Modell entscheidet, ob eine Änderung gut ist, sondern der Regelsatz des Servers. Ein Measure-Vorschlag, der gegen eine kritische Regel verstößt, kommt als Befund zurück, nicht als Änderung.

• Werkzeuge entdecken: Der Server beschreibt, was er kann — in Sprache, nicht in Code.
• Werkzeug aufrufen: Lesend auf Metadaten; schreibend nur über Vorschläge.
• Regelprüfung: Jeder Vorschlag wird gegen den Regelsatz geprüft, bevor ein Mensch ihn sieht.
• Protokoll: Jeder Aufruf mit Zeitstempel, Werkzeug und Parametern — prüfbar.

Die drei Begriffe werden in Gesprächen oft vermischt. Die Tabelle zeigt, für wen sie gebaut sind, in welche Richtung Daten fließen und was ein Agent damit anfangen kann.

Weil der Server entscheidet, was der Agent darf, ist seine Konfiguration die Sicherheitsarchitektur. Die zwölf Fragen der Checkliste prüfen genau das: Liefert der Server nur Metadaten oder auch Werte? Welche Werkzeuge schreiben? Gibt es einen Regelsatz, und wer pflegt ihn? Wird jeder Aufruf protokolliert, und wer darf das Protokoll lesen? Welche Identität nutzt der Server gegenüber dem Modell — eine Dienstidentität oder die des Nutzers? Was passiert bei einem Fehler mitten in einer Änderung?

Wer diese Fragen beantworten kann, hat die Freigabestellen definiert, die im nächsten Kapitel beschrieben sind. Wer sie nicht beantworten kann, hat einen Server, der zu viel darf.

Die Checkliste in Kurzform. Jede Frage hat eine erwartete Antwort; eine andere Antwort ist kein Ausschluss, aber ein Punkt für das Gespräch mit IT-Sicherheit und Datenschutz, bevor der Server produktiv geht.

• 1 Liefert der Server nur Metadaten oder auch Werte? Nur Metadaten; Werte höchstens aggregiert und explizit freigeschaltet.
• 2 Welche Werkzeuge schreiben? Keines direkt; Schreibzugriffe erzeugen Vorschläge (PBIP, TMDL, SQL-Datei), die ein Mensch einspielt.
• 3 Gibt es einen Regelsatz, und wer pflegt ihn? Ja, versioniert; Pflege durch BI-Leitung, Änderungen protokolliert.
• 4 Wird jeder Aufruf protokolliert, und wer liest das Protokoll? Ja, mit Zeitstempel, Werkzeug, Parametern; lesbar für Auftraggeber und Datenschutz.
• 5 Mit welcher Identität arbeitet der Server? Dienstidentität mit minimalen Rechten oder die des Nutzers; nie ein Admin-Konto.
• 6 Was passiert bei einem Fehler mitten in einer Änderung? Vorschläge sind atomar und versioniert; nichts Halbes landet im Modell.
• 7 Wo läuft der Server? Lokal auf dem Arbeitsplatz oder im eigenen Tenant; nicht als Dienst eines Dritten mit Zugriff auf Ihr Modell.
• 8 Welche Modelle und Anbieter sind erreichbar? Eine benannte Liste, mit Region; Wechsel nur mit Zustimmung.
• 9 Gibt es Grenzen für Aufrufe und Kosten? Ja: Rate-Limits je Nutzer, Token-Budget je Projekt, Warnung bei 80 Prozent.
• 10 Wie werden Vorschläge versioniert? Als Dateien in Git (PBIP, TMDL), Freigabe als Pull Request, nicht als Klick in einer Oberfläche.
• 11 Wie sieht die Freigabe technisch aus? Zwei-Augen-Prinzip im Repository, Lineage-Befund und Regelprüfung hängen am Vorschlag.
• 12 Gibt es einen Notaus? Ja: Entzug der Dienstidentität stoppt alle Werkzeuge sofort, ohne das Modell zu berühren.

Die Werkzeuge entscheiden, was ein Agent überhaupt tun kann. Die Tabelle zeigt den Satz, den wir in Projekten einsetzen, mit Richtung und einem Beispielaufruf, so wie das Modell ihn versteht. Alles Lesende arbeitet auf Metadaten; alles Schreibende erzeugt Vorschläge.