Remote Power BI MCP Server

Dirk Müller
15. Juli
8 Min. Lesezeit

Aktualisiert: vor 7 Tagen

Unternehmen haben viel Zeit in Power-BI-Modelle investiert. Dort liegen nicht nur Daten, sondern Beziehungen, Kennzahlen, Zeitlogiken und fachliche Definitionen. Trotzdem enden viele Fragen noch immer in einem neuen Bericht, einer zusätzlichen Exportdatei oder einer Anfrage an das BI-Team.

Der Remote Power BI MCP Server eröffnet einen anderen Zugang: Ein KI-Agent erhält Werkzeuge, um ein vorhandenes semantisches Modell zu untersuchen, DAX-Abfragen zu erzeugen und Ergebnisse in natürlicher Sprache aufzubereiten.

Warum ist der Umsatz in einer Region gesunken?
Welche Kunden weichen besonders stark vom Forecast ab?
Welche Produktgruppen entwickeln sich schlechter als im Vorjahr?
Wo steigen Kosten, obwohl die Absatzmenge stabil bleibt?

Technisch ist das inzwischen möglich. Vertrauenswürdig wird es dadurch aber noch nicht automatisch. Der Remote MCP Server macht Power-BI-Semantik für KI-Agenten nutzbar. Gute Antworten entstehen jedoch erst durch ein sauberes Modell, AI Readiness, kontrollierte Berechtigungen und einen geprüften MCP-Client.

Warum Power BI Remote MCP braucht

Klassische Schnittstellen sind für Anwendungen gebaut, deren Entwickler im Voraus wissen, welche Funktion aufgerufen werden soll. Ein KI-Agent arbeitet anders. Er muss erkennen, welche Werkzeuge verfügbar sind, welche davon zur Frage passen und welche Parameter benötigt werden.

Das Model Context Protocol standardisiert diese Verbindung. Ein Host stellt die Umgebung bereit, ein MCP-Client interpretiert die Nutzeranfrage und ein MCP-Server stellt klar beschriebene Werkzeuge für das angebundene System bereit.

Beim Remote Power BI MCP Server liegt der Server nicht auf dem Rechner des Nutzers. Microsoft betreibt ihn als Fabric-Endpunkt. Der Agent erhält damit einen strukturierten Zugang zu Tabellen, Spalten, Measures, Beziehungen, Hierarchien und ausgewählten Reportmetadaten.

Wer zunächst die Grundlagen und den lokalen Entwicklungsansatz verstehen möchte, findet in unserer Power BI MCP Einführung die Einordnung des Protokolls und des Modeling MCP Servers.

So verarbeitet Remote MCP eine Frage

Eine Frage wie „Welche Produktgruppen haben im zweiten Quartal gegenüber dem Vorjahr Umsatz verloren?“ führt nicht direkt zu einer fertigen Antwort. Dazwischen liegt ein mehrstufiger Prozess.

Der MCP-Client erhält die fachliche Frage.
Er fragt das Schema des semantischen Modells ab.
Relevante Tabellen, Measures und Beziehungen werden ausgewählt.
Aus Frage und Schema wird eine DAX-Abfrage erzeugt.
Die Abfrage wird gegen das Power-BI-Modell ausgeführt.
Das Ergebnis wird an den Client zurückgegeben und sprachlich aufbereitet.

Der Server kann derzeit Modell-Schemas und Reportmetadaten abrufen, DAX aus natürlicher Sprache erzeugen und DAX-Abfragen ausführen. Reportmetadaten liefern zusätzlichen Kontext darüber, wie Felder, Filter und Measures bereits in Berichten verwendet werden.

Der Remote Power BI MCP Server selbst hält keinen dauerhaften Gesprächszustand. Den Kontext zwischen Folgefragen verwaltet der verwendete MCP-Client beziehungsweise dessen Sprachmodell.

Remote MCP und Modeling MCP

Microsoft bietet zwei Power-BI-MCP-Ansätze an. Sie lösen unterschiedliche Aufgaben und sollten nicht verwechselt werden.

Remote MCP: bestehende Modelle abfragen, Metadaten lesen und DAX für Analysen erzeugen.
Modeling MCP: Measures, Beziehungen und Modellobjekte erstellen oder verändern.

Ein Agent, der eine Umsatzfrage beantworten soll, benötigt Remote MCP. Ein Agent, der das Umsatz-Measure überarbeiten soll, benötigt Modeling MCP. Diese Trennung ist auch organisatorisch sinnvoll. Analysezugriff und Modelländerung sind unterschiedliche Risikoklassen und sollten nicht über dieselben Rollen und Freigaben gesteuert werden.

Voraussetzungen für Remote MCP

Für einen ersten Test benötigt ein Unternehmen mehr als einen Endpunkt. Ein Power-BI-Administrator muss die relevante Tenant-Einstellung aktivieren. Der Nutzer braucht einen MCP-kompatiblen Client sowie mindestens Build-Berechtigung auf dem semantischen Modell. Für Copilot-gestützte DAX-Erzeugung müssen außerdem die passenden Lizenz- und Capacity-Voraussetzungen erfüllt sein.

Der technisch einfache Teil ist die Verbindung. Die wichtigere Frage lautet: Welches Modell sollte überhaupt für einen KI-Agenten freigegeben werden?

fachlich klar abgegrenzt
stabile und dokumentierte Measures
überschaubare Zahl relevanter Objekte
realistische und wiederkehrende Fachfragen
getestete Berechtigungen und RLS-Regeln

Warum Build-Rechte kritisch sind

Build ist keine harmlose Leseberechtigung. Nutzer mit Build-Rechten können ein semantisches Modell wiederverwenden, darauf neue Inhalte erstellen, Daten in anderen Werkzeugen auswerten und je nach Umgebung weitere Zugriffspfade nutzen.

Wer einem Agenten Power-BI-Zugriff ermöglicht, muss deshalb klären, unter wessen Identität der Agent arbeitet und welche Möglichkeiten diese Identität bereits besitzt.

Die Grundlagen zu Read, Build, Workspace-Rollen und RLS haben wir unter Power-BI-Berechtigungen verstehen ausführlich eingeordnet.

Das Modell entscheidet über Qualität

Ein Agent kann nur mit der Semantik arbeiten, die das Modell bereitstellt. Sprechende Dimensionen, eindeutige Measures und nachvollziehbare Beziehungen bieten eine gute Grundlage. Technische Namen, mehrere ähnliche Umsatzkennzahlen und nicht dokumentierte Sonderfälle erzeugen dagegen schnell plausible, aber falsche Antworten.

KI macht ein schwaches Modell nicht besser. Sie macht seine Schwächen nur schneller sichtbar.

Für AI Readiness sind vor allem drei Elemente relevant: Ein AI Data Schema begrenzt die relevanten Objekte, AI Instructions beschreiben fachliche Begriffe und Regeln, und Verified Answers hinterlegen geprüfte Antwortpfade für wiederkehrende Fragen.

Beispielsweise kann eine Instruction festlegen, dass für Umsatz immer das Measure „Net Revenue“ verwendet wird, dass Forecast-Fragen auf die aktuelle freigegebene Version zielen und dass mit „Kunde“ der Rechnungsempfänger gemeint ist.

Der Zusammenhang mit Data Contracts ist unmittelbar: Ein Agent braucht nicht nur Tabellen, sondern klare Definitionen, Ownership und verlässliche Datenprodukte.

Praxisbeispiel: Umsatz analysieren

Ein Vertriebsleiter fragt: „Warum ist der Umsatz in der Region Süd im zweiten Quartal gesunken?“ Ein gut vorbereitetes Modell stellt dafür Nettoumsatz, Vorjahresumsatz, Absatzmenge, Durchschnittspreis, Region, Produktgruppe, Kunde und Quartal eindeutig bereit.

Der Remote MCP Server kann daraus eine DAX-Abfrage erzeugen, die Umsatzvergleich, Preisentwicklung und Kundenbeiträge aufschlüsselt. Das Ergebnis könnte zeigen: Umsatz minus acht Prozent, Absatzmenge minus zwei Prozent, Durchschnittspreis minus sechs Prozent und zwei Großkunden mit deutlich geringeren Bestellungen.

Der Agent kann daraus ableiten, dass der Rückgang vor allem preis- und kundengetrieben ist. Trotzdem bleiben fachliche Fragen offen: Wurde das richtige Datumsfeld verwendet? Sind Stornos enthalten? Gibt es Währungseffekte? Hat RLS einzelne Kunden ausgeblendet?

Der Agent kann Auffälligkeiten erklären. Er ersetzt nicht automatisch die fachliche Ursachenanalyse.

RLS schützt nicht die ganze Kette

Bei interaktiver Benutzeranmeldung führt der Remote Power BI MCP Server Abfragen im Kontext des angemeldeten Nutzers aus. Power BI RLS wird dabei berücksichtigt.

Kritisch wird es bei Service Principals: Nach aktueller Microsoft-Dokumentation wird RLS bei dieser Authentifizierungsart nicht erzwungen. Ein gemeinsam genutzter oder automatisierter Agent kann dadurch deutlich weitergehenden Datenzugriff erhalten als erwartet.

Hinzu kommt: Die Sicherheitsgrenze endet nicht beim Power-BI-Dienst. Metadaten und Abfrageergebnisse werden an den MCP-Client übergeben und können dort durch ein externes Sprachmodell verarbeitet werden.

Eine belastbare Power BI Governance muss deshalb festlegen, welche Clients und LLM-Anbieter erlaubt sind, welche Modelle freigegeben werden, wer Build-Rechte erhält und wie Agenteninteraktionen geprüft werden.

Remote MCP, Copilot oder Data Agent?

Nicht jedes Conversational-Analytics-Szenario benötigt denselben Ansatz. Power BI Copilot passt für Fragen direkt in Power BI. Der Remote Power BI MCP Server eignet sich, wenn ein eigenes MCP-kompatibles Frontend oder ein individuell entwickelter Agent angebunden werden soll.

Fabric Data Agents sind dagegen eigenständige Fabric-Artefakte, die neben semantischen Modellen auch weitere Fabric-Datenquellen einbeziehen können. Mehr dazu findet ihr in unserer Einordnung zu Fabric Data Agents.

Fragen direkt in Power BI: Power BI Copilot
Eigenen MCP-Client anbinden: Remote Power BI MCP Server
Mehrere Fabric-Datenquellen kombinieren: Fabric Data Agent
Semantisches Modell verändern: Modeling MCP Server

Die Entscheidung sollte vom Nutzungsszenario ausgehen und nicht davon, welches Feature aktuell am spannendsten wirkt.

Warum MCP für Fabric Data Agents jetzt wichtiger wird

Mit dem Remote Power BI MCP Server ist MCP inzwischen mehr als ein experimenteller Zugang zu Power BI. Microsoft etabliert das Model Context Protocol zunehmend als Schnittstelle, über die AI Agents mit Daten und Funktionen der Microsoft-Datenplattform interagieren können. Der Remote Power BI MCP Server stellt dafür Werkzeuge bereit, mit denen Agents beispielsweise Schemainformationen aus semantischen Modellen abrufen sowie DAX-Abfragen generieren und ausführen können.

Besonders sichtbar wird diese Entwicklung bei Fabric Data Agents. Für externe Anwendungen dokumentiert Microsoft bislang unter anderem eine Implementierung auf Basis der OpenAI Assistants API. Diese API wird jedoch zum 26. August 2026 eingestellt. Microsoft empfiehlt deshalb, entsprechende Integrationen auf den MCP-Endpunkt zu migrieren.

Für Unternehmen ist das ein deutliches Signal, MCP nicht mehr nur als Entwickler

-Experiment, sondern als relevante Integrationsschicht für AI Agents einzuplanen. Der Remote Power BI MCP Server selbst ist von dieser Abschaltung nicht betroffen: Er basiert bereits auf MCP und befindet sich aktuell in Preview.

Dabei sollten Remote Power BI MCP und Fabric Data Agents nicht gleichgesetzt werden. Der Remote Power BI MCP Server verbindet AI Agents gezielt mit bestehenden Power BI Semantic Models. Microsoft unterscheidet außerdem zwischen dem Remote MCP Server für Abfrage- und Analyseszenarien und dem lokalen Power BI MCP Server für die Entwicklung und Änderung semantischer Modelle.

Was MCP für Berechtigungen und Semantic Models bedeutet

Mit der technischen Anbindung allein ist ein produktives Agent-Szenario noch nicht gelöst. Entscheidend ist, unter welcher Identität ein Agent arbeitet, welche Berechtigungen gelten und auf welche Semantic Models er zugreifen darf. Beim Remote Power BI MCP Server benötigen Benutzer mindestens Build-Berechtigungen auf dem jeweiligen Semantic Model.

Auch bestehende Sicherheitsmechanismen müssen berücksichtigt werden. Bei Benutzerauthentifizierung wird RLS angewendet. Für Service-Principal-Authentifizierung weist Microsoft dagegen aktuell auf Einschränkungen im Zusammenspiel mit RLS hin. Gerade bei produktiven Agent-Szenarien gehört das Berechtigungsmodell deshalb früh in die Architekturentscheidung.

Gleichzeitig steigt die Bedeutung der Modellqualität. Der MCP Server kann Schema, Measures, Beziehungen und weitere Metadaten auslesen und daraus DAX-Abfragen erzeugen. Er kann aber keine fehlende fachliche Semantik reparieren. Unklare Bezeichnungen, schlecht dokumentierte Measures oder fachlich mehrdeutige Modelle bleiben auch für einen AI Agent problematisch.

Deshalb gehört MCP eng mit der Frage zusammen, wie Unternehmen ihre semantischen Modelle für KI vorbereiten. AI Instructions, aussagekräftige Metadaten und Verified Answers können dazu beitragen, Semantic Models zuverlässiger für Copilot- und Agent-Szenarien nutzbar zu machen. MCP schafft also den technischen Zugang – die Qualität der Antworten entscheidet sich weiterhin wesentlich im Datenmodell und dessen Governance.

Grenzen des Remote MCP Servers

Der Remote Power BI MCP Server ist vielversprechend, aber noch kein Ersatz für Reporting, Governance und Analyseprozesse.

Die Funktion befindet sich weiterhin in der Preview.
Komplexe DAX-Logik wird nicht immer korrekt aus Sprache übersetzt.
Große Modelle erzeugen umfangreiche Schemakontexte.
Antwortqualität bleibt nicht deterministisch.
Performance hängt stark von Modell und erzeugter DAX-Abfrage ab.
Fachliche Ursachen müssen weiterhin validiert werden.

Ein überzeugender Demo-Dialog ist noch kein belastbarer Business Case.

So gelingt ein kontrollierter Pilot

Ein fachlich klar abgegrenztes Modell auswählen.
Zehn bis fünfzehn reale Fachfragen sammeln.
Erwartete Antworten und Measures dokumentieren.
AI Data Schema und AI Instructions vorbereiten.
Build-Rechte und RLS mit Testnutzern prüfen.
Erzeugte DAX-Abfragen technisch und fachlich validieren.
Antworten über unterschiedliche Formulierungen testen.
Fehler kategorisieren und das Modell gezielt verbessern.

Das Ziel des Piloten ist nicht, möglichst viele Fragen zu beantworten. Es ist herauszufinden, für welche Fragen dem Agenten vertraut werden kann.

Fazit: Agenten brauchen Semantik

Der Remote Power BI MCP Server ist strategisch relevant, weil er vorhandene semantische Modelle für neue Agenten- und Assistenzszenarien öffnet. Unternehmen müssen ihre Kennzahlenlogik nicht zwangsläufig in einer separaten KI-Datenbank neu aufbauen. Das ist eine große Chance. Es ist aber keine Abkürzung.

Je stärker Unternehmen Power-BI-Daten über KI-Agenten zugänglich machen, desto wichtiger werden saubere Modelle, eindeutige Kennzahlen, kontrollierte Rechte und überprüfbare Antworten. Remote Power BI MCP zeigt damit sehr konkret, was AI Readiness in der Praxis bedeutet.

Der nächste sinnvolle Schritt

Wenn ihr prüfen wollt, ob der Remote Power BI MCP Server für euch mehr ist als eine überzeugende Demo, braucht es einen klar abgegrenzten und kontrollierten Pilot. Entscheidend ist nicht, wie schnell ein Agent eine Antwort formuliert, sondern ob semantisches Modell, Berechtigungen, AI Instructions und Validierung belastbar genug sind.

Der nächste sinnvolle Schritt beginnt deshalb mit einem geeigneten Modell, realen Fachfragen und einer ehrlichen Bewertung der Antwortqualität.

Wenn du Power BI strukturiert aufsetzen oder bestehende Lösungen verbessern willst, unterstützen wir dich mit:

Data Strategy Check – um Datenprodukte, AI Readiness und Verantwortlichkeiten ganzheitlich einzuordnen
Consulting Abo – für kontinuierliche Unterstützung bei Pilot, Governance und Betrieb
Power BI Coaching – für konkrete Herausforderungen in Modellen, DAX und AI Readiness
Microsoft Fabric Kick Start – für einen praxisnahen Einstieg in Architektur, Zielbild und ersten Remote-MCP-Use-Case

So wird aus einem funktionierenden Agenten-Demo eine belastbare Analytics-Lösung.

FAQ zu Remote Power BI MCP

Kann der Remote MCP Server Modelle verändern? Nein. Sein Schwerpunkt liegt auf Schema- und Metadatenzugriff, DAX-Generierung und Datenabfragen. Für Modelländerungen ist der Modeling MCP Server vorgesehen.

Welche Berechtigungen werden benötigt? Der Nutzer benötigt mindestens Build-Berechtigung auf dem semantischen Modell. Zusätzlich muss die relevante Tenant-Einstellung aktiviert sein.

Wird Power BI RLS unterstützt? Bei interaktiver Benutzeranmeldung wird RLS berücksichtigt. Bei Service-Principal-Authentifizierung wird RLS derzeit nicht erzwungen.

Funktioniert Remote MCP nur mit GitHub Copilot? GitHub Copilot in Visual Studio Code ist der dokumentierte Einstieg. Grundsätzlich ist der Server für MCP-kompatible Clients ausgelegt.

Ist der Remote Power BI MCP Server produktionsreif? Die Funktion befindet sich weiterhin in der Public Preview. Kritische oder regulatorisch relevante Szenarien sollten deshalb zunächst kontrolliert getestet werden.