Fabric Data Warehouse MCP Server: Agentic SQL sicher einsetzen

vor 5 Stunden

5 Min. Lesezeit

Mit dem Fabric Data Warehouse MCP Server können AI-Agenten direkt gegen ein Microsoft Fabric Warehouse oder einen SQL Analytics Endpoint arbeiten. Das klingt zunächst wie ein weiterer bequemer Datenzugriff. Tatsächlich ist die Funktion weitreichender: Der Server stellt mit executeSQL ein Werkzeug bereit, das – innerhalb der Rechte des angemeldeten Nutzers – T-SQL ausführen kann. Damit reicht das Spektrum von Metadatenabfragen und Analyse bis zu schreibenden DDL- und DML-Operationen.

Genau deshalb ist der Server weniger ein Chat-Feature als eine neue Ausführungsgrenze für Agentic Analytics. Wer ihn produktiv einsetzen will, muss Endpoint-Scope, Identitäten, SQL-Rechte, Query-Review und Human Approval gemeinsam entwerfen.

Was ist der Fabric Data Warehouse MCP Server?

Der Fabric Data Warehouse MCP Server ist ein von Microsoft gehosteter MCP-Endpunkt für Fabric Data Warehouse und SQL Analytics Endpoints. Ein kompatibler AI-Agent kann darüber T-SQL generieren, zur Ausführung vorlegen, Ergebnisse lesen und auf Basis des realen Warehouse-Kontexts weiterarbeiten.

Der Produktstatus ist aktuell Preview. Damit eignet sich der Server für kontrollierte Pilot- und Entwicklungsworkflows, sollte aber nicht wie eine unveränderliche Produktionsschnittstelle behandelt werden. Endpunkte, Tool-Vertrag und Betriebsgrenzen können sich weiterentwickeln.

Globaler oder item-scoped Endpoint?

Microsoft bietet zwei Varianten. Der globale Endpoint ist flexibel: Der Agent bekommt Warehouse-Kontext über Prompt beziehungsweise Tool-Aufruf und kann dadurch mit unterschiedlichen Warehouses arbeiten. Das ist praktisch für Entwickler, Plattformteams und Diagnose-Szenarien, bei denen das Ziel dynamisch gewählt wird.

Der item-scoped Endpoint bindet die MCP-Verbindung an genau ein Warehouse-Item. Workspace-ID und Item-ID stehen direkt in der Endpoint-URL. Dadurch muss der Agent den Warehouse-Kontext nicht wiederholt aus dem Gespräch ableiten.

Der item-scoped Endpoint ersetzt keine Berechtigungen. Er reduziert aber die Wahrscheinlichkeit, dass ein Agent versehentlich gegen das falsche Warehouse arbeitet. Für produktionsnahe Agenten ist diese zusätzliche Begrenzung oft sinnvoll.

Ein Tool: executeSQL

Der Server exponiert genau ein Tool: executeSQL. Es führt ein genehmigtes T-SQL-Statement gegen das Fabric Warehouse aus und gibt das Ergebnis zurück.

Separate Werkzeuge für Schema-Discovery, Tabellenbeschreibung, Query History oder Monitoring gibt es nicht. Solche Aufgaben werden ebenfalls mit T-SQL gelöst – beispielsweise über INFORMATION_SCHEMA, DMVs oder andere verfügbare Systemansichten.

Diese Reduktion ist architektonisch interessant: Das Toolset ist klein, aber die mögliche Wirkung groß. Discovery, Abfrage, Troubleshooting, Monitoring und Objektänderungen laufen alle über dieselbe technische Fähigkeit. Governance muss deshalb stärker auf das erzeugte SQL und die Identität schauen als auf den Toolnamen.

Was ein Agent damit praktisch tun kann

Für den Einstieg sind lesende Aufgaben besonders geeignet. Ein Agent kann Schemas, Tabellen und Views inventarisieren, Spaltenstrukturen erklären, Datenqualität untersuchen, Kennzahlen ad hoc analysieren oder Query-Aktivität auswerten, sofern die notwendigen Systemansichten verfügbar sind.

Auch Performance- und Troubleshooting-Szenarien sind naheliegend: lange laufende Queries identifizieren, Fehlermuster gruppieren, Join- und Filterlogik erklären oder eine bestehende Abfrage in verständlicher Form neu strukturieren.

Der gleiche Mechanismus kann jedoch auch CREATE, ALTER, DROP, INSERT, UPDATE oder DELETE ausführen, wenn der angemeldete Nutzer diese Rechte besitzt. Die Grenze zwischen Analyse-Assistent und ausführendem Engineering-Agenten liegt deshalb nicht im MCP-Server selbst, sondern in Berechtigungen und Freigabeprozess.

Identität und Berechtigungen: MCP umgeht Fabric Security nicht

Der Server arbeitet mit der Identität des angemeldeten Nutzers. Er übernimmt damit die vorhandenen Fabric-Workspace-, Item- und SQL-Berechtigungen. Ein MCP-Aufruf kann keine Rechte erzeugen, die der Nutzer nicht besitzt.

Das ist eine wichtige Basis, aber noch kein vollständiges Sicherheitsmodell. Hat ein Entwickler im Produktions-Warehouse weitreichende SQL-Rechte, kann ein Agent mit derselben Identität diese Rechte ebenfalls nutzen. Least Privilege bleibt deshalb die wichtigste technische Kontrollschicht.

Für Piloten sollten eigene Entwicklungs- oder Test-Warehouses, klar begrenzte Identitäten und möglichst lesende SQL-Rechte verwendet werden. Schreibrechte sollten erst hinzukommen, wenn Query-Review, Logging, Recovery und Approval belastbar funktionieren.

Human Approval vor schreibenden Operationen

Microsoft empfiehlt, executeSQL-Aufrufe im MCP-Client explizit genehmigen zu lassen und insbesondere schreibende Statements vor der Ausführung zu prüfen. Für produktive Warehouses sollte daraus eine verbindliche Regel werden: Kein schreibendes SQL ohne sichtbares Statement und menschliche Freigabe.

Dabei reicht ein generisches „Tool ausführen?“ nicht. Die prüfende Person sollte mindestens Ziel-Warehouse, SQL-Statement, betroffene Objekte, erwartete Wirkung und – bei Änderungen – den Recovery-Pfad sehen.

Für DROP, größere UPDATE/DELETE-Operationen oder Schemaänderungen kann ein zusätzlicher Gate sinnvoll sein: Change Ticket, Pull Request oder eine separate Deployment-Pipeline statt direkter interaktiver Ausführung.

Ein sicherer Pilot beginnt read-only

Ein sinnvoller Einstieg kann in vier Stufen erfolgen:

Discovery: Schemas, Tabellen, Views und Metadaten ausschließlich lesen.
Analyse: SELECT-Abfragen für fachliche Exploration und Troubleshooting ausführen.
Query Review: Der Agent erzeugt SQL, führt es aber erst nach menschlicher Prüfung aus.
Kontrollierte Writes: Nur klar abgegrenzte Schreiboperationen in Development/Test und erst nach etablierten Review- und Recovery-Regeln.

Dieser Pfad trennt Nutzenvalidierung von Autonomie. Teams können sehr früh prüfen, ob der Agent Warehouse-Kontext korrekt versteht, ohne dafür bereits produktive Schreibrechte zu benötigen.

Logging und Nachvollziehbarkeit gehören zum Design

Wer agentische SQL-Ausführung produktiv betrachtet, sollte jeden relevanten Vorgang nachvollziehen können: Wer hat den Agenten ausgelöst? Gegen welches Warehouse wurde gearbeitet? Welches SQL wurde vorgeschlagen? Wer hat es genehmigt? Was wurde ausgeführt und mit welchem Ergebnis?

Die vorhandenen Fabric-Monitoring-Möglichkeiten können dafür einen Teil der technischen Sicht liefern. Ein eigener Governance-Log für Agent-Interaktionen ist trotzdem sinnvoll, weil er die Verbindung zwischen Prompt, generiertem SQL, Approval und Ausführung dokumentiert.

Das ist besonders bei Fehleranalysen wichtig. Ohne diese Kette lässt sich später zwar eine problematische Query finden, aber nicht zuverlässig erklären, warum der Agent sie erzeugt und wer sie freigegeben hat.

Abgrenzung zu Power BI Authoring MCP

Der Power BI Authoring MCP Server adressiert semantische Modelle: Measures, Tabellen, Beziehungen, Rollen und weitere Modellobjekte. Der Fabric Data Warehouse MCP Server adressiert dagegen die SQL-Schicht eines Warehouses oder SQL Analytics Endpoints.

Beide können in einem Agentic-Analytics-Workflow zusammenspielen, sollten aber unterschiedliche Rechte und Reviewregeln haben. Ein Agent, der ein Warehouse-Schema ändert, operiert auf einer anderen Risikostufe als ein Agent, der ein Measure in einem Entwicklungsmodell anpasst.

Abgrenzung zu Fabric IQ

Fabric IQ ist die read-only Consumption-Schicht für Power-BI-Berichte und semantische Modelle. Dort geht es um Discovery, Metadaten und DAX-basierte Datenabfragen für Business-Fragen. Fabric IQ ist allgemein verfügbar und respektiert bestehende Fabric-, RLS- und OLS-Berechtigungen.

Der Warehouse MCP Server ist dagegen SQL-orientiert und kann – bei entsprechenden Nutzerrechten – auch schreibende Statements ausführen. Wer Business-Fragen an ein kuratiertes Semantic Model beantworten möchte, braucht deshalb nicht automatisch Warehouse-MCP-Zugriff.

Abgrenzung zu Fabric Data Agents

Fabric Data Agents adressieren einen anderen Layer: Sie kapseln ein agentisches Datenprodukt mit konfigurierten Datenquellen, Instructions und einem eigenen Betriebsmodell. API, SDK, Evaluation und MCP-Zugriff machen sie zu betreibbaren Agent-Artefakten.

Der Warehouse MCP Server ist dagegen eine direkte Werkzeuggrenze zur SQL-Ausführung. Er ersetzt weder den fachlichen Agent-Entwurf noch Evaluation, Versionierung oder Governance eines Data Agents.

Abgrenzung zu Data Factory MCP

Data Factory MCP adressiert Datenintegrations- und Orchestrierungsaufgaben. Warehouse MCP arbeitet direkt auf der SQL-Ebene des Warehouses. Ein Agent kann damit Daten und Objekte untersuchen oder verändern, aber er ersetzt nicht automatisch Pipelines, Dataflows, Deployment-Logik oder einen orchestrierten Datenbewegungsprozess.

Entscheidungsmatrix: Wann ist Warehouse MCP sinnvoll?

Governance-Checkliste vor dem ersten produktionsnahen Einsatz

Endpoint-Scope bewusst wählen: global oder item-scoped.
Separate Identität und Least-Privilege-Rechte definieren.
Read-only als Startzustand festlegen.
Generiertes SQL vor jeder Ausführung sichtbar machen.
Schreibende Statements immer menschlich freigeben lassen.
Produktive DDL/DML möglichst in versionierte Deployment-Wege überführen.
Prompt, SQL, Approval und Ergebnis nachvollziehbar protokollieren.
Recovery für fehlerhafte Änderungen vor dem Ausbau der Autonomie testen.

Fazit: Agentic SQL braucht eine klare Ausführungsgrenze

Der Fabric Data Warehouse MCP Server macht T-SQL für AI-Agenten unmittelbar nutzbar. Sein Design ist bewusst einfach: zwei Endpoint-Varianten, ein Werkzeug, die vorhandenen Fabric- und SQL-Rechte. Gerade diese Einfachheit darf nicht mit geringem Risiko verwechselt werden.

Für produktive Szenarien ist deshalb nicht die Frage entscheidend, ob ein Agent SQL generieren kann. Entscheidend ist, welche Identität welche Statements gegen welches Warehouse nach welchem Review ausführen darf.

Ein read-only Pilot, item-scoped Verbindungen, Least Privilege, sichtbares Query Review und verbindliches Human Approval für Writes schaffen dafür eine belastbare Basis. Erst wenn diese Kontrollkette funktioniert, sollte der Scope schrittweise erweitert werden.

Nächster Schritt

Wenn ihr Fabric Data Warehouse, MCP und Agentic Analytics kontrolliert in eure Datenplattform integrieren wollt, unterstützen wir euch im Microsoft Fabric Kick Start dabei, Pilot-Scope, Berechtigungen, Governance-Gates und den technischen Betriebsweg festzulegen.