Power BI MCP-server: én til at spørge, én til at bygge

Af /

En Power BI MCP-server lader en AI-agent arbejde direkte med jeres semantiske model. Microsoft har to, begge i public preview: en remote server, der stiller spørgsmål til modellen, og en lokal modeling-server, der redigerer tabeller, measures og relationer. Begge er kun så gode som modellen. Navne, beskrivelser og definitioner afgør, om agenten svarer rigtigt eller gætter.

Resumé og konklusion

  • Der er to servere med hver sin opgave. Den remote server forespørger publicerede modeller. Den lokale Power BI Modeling MCP Server bygger og ændrer modeller i Power BI Desktop, i en Fabric-workspace eller i en PBIP-mappe.
  • Begge er i public preview. Microsoft skriver, at værktøjsdefinitioner og svarformater kan ændre sig. Byg ikke en forretningskritisk proces på dem endnu.
  • Den remote server kræver en tenant-indstilling og Build-rettighed. RLS håndhæves, når brugeren selv logger ind, men ikke med en service principal.
  • Svarkvaliteten afgøres i modellen. Agenten ser tabeller, kolonner, measures, relationer og beskrivelser. Er de navngivet og beskrevet, har den noget at arbejde med. Er de ikke, gætter den.
  • Modeling-serveren er et udviklerværktøj. Den kan ændre alt i modellen, fylder meget i agentens kontekstvindue og hører til på en kopi under Git med et menneske, der godkender.

To Power BI MCP-servere: én til at spørge, én til at bygge

Microsoft beskriver i oversigten over Power BI MCP-serverne to implementeringer. Den remote server er en tjeneste, som Fabric hoster, og som klienten når over HTTP med login i Microsoft Entra ID. Den bruges til at stille spørgsmål til modeller, der allerede er publiceret. Den lokale server kører på udviklerens egen maskine via Visual Studio Code eller Node.js 20 og bruges til at bygge og ændre modeller.

Forskellen afgør, hvem der skal have hvad. En controller, der vil spørge til omsætningen, har brug for den remote server og læseadgang. En Power BI-udvikler, der skal skrive 40 beskrivelser eller rette en relation, har brug for modeling-serveren og skriverettigheder. Microsoft skriver selv, at klienterne arbejder med brugerens Fabric-rettigheder, og at autonome klienter kan udføre destruktive handlinger.

Grafikken herunder stiller de to servere op mod hinanden.

Power BI MCP-server: remote server til spørgsmål og modeling-server til udvikling
Den remote server spørger publicerede modeller. Modeling-serveren ændrer modellen lokalt eller i en workspace.

Den remote Power BI MCP-server: fire værktøjer til at spørge

Den remote server har fire værktøjer:

  • Get Semantic Model Schema. Henter tabeller, kolonner, measures, relationer, datatyper og hierarkier, og Copilot-metadata, hvis modellen har det.
  • Generate Query. Oversætter et spørgsmål i naturligt sprog til DAX med Copilot i Power BI. Kræver en Copilot-licens, og Copilot i Power BI kræver betalt Fabric-kapacitet fra F2 eller Premium fra P1.
  • Execute Query. Kører en DAX-forespørgsel mod modellen og returnerer resultatet. Kræver Build-rettighed og kører i brugerens kontekst.
  • Get Report Metadata. Henter sider, visuals, filtre og feltbindinger fra en rapport.

Opsætningen i Microsofts vejledning til den remote server er beskrevet for Visual Studio Code med GitHub Copilot: en mcp.json med typen http og URL’en https://api.fabric.microsoft.com/v1/mcp/powerbi. Administratoren skal først slå tenant-indstillingen “Users can use the Power BI Model Context Protocol server endpoint (preview)” til. Serveren følger MCP-specifikationen, så andre MCP-klienter kan i princippet bruge den, men dokumentationen viser kun GitHub Copilot.

To begrænsninger er værd at kende. RLS håndhæves, når brugeren selv er logget ind, men ikke med en service principal, som ser alt, den har adgang til. Og hver forespørgsel kører uafhængigt. Serveren husker ikke samtalen, det gør klienten. Modeller med hundredvis af tabeller giver store svar fra Get Semantic Model Schema, og det koster plads i agentens kontekst.

Power BI Modeling MCP Server: når agenten redigerer modellen

Modeling-serveren ligger på github.com/microsoft/powerbi-modeling-mcp og installeres som udvidelsen Power BI Modeling MCP i Visual Studio Code eller via npx. Den forbinder til en åben fil i Power BI Desktop, en semantisk model i en Fabric-workspace eller en PBIP-mappe med TMDL-filer.

Værktøjerne dækker hele modellen, blandt andet table_operations, column_operations, measure_operations, relationship_operations, partition_operations, security_role_operations, culture_operations, object_translation_operations, dax_query_operations og transaction_operations med begin, commit og rollback. Det gør bulk-opgaver realistiske, fx at skrive beskrivelser på alle measures i en display-mappe eller oversætte nye objekter til tre sprog.

Som standard beder serveren om bekræftelse før den første ændring og den første forespørgsel. Med –readonly kan den kun læse, og med –skipconfirmation forsvinder bekræftelsen. Microsoft anbefaler backup af modellen før hver opgave, fordi sprogmodellen kan lave uventede ændringer.

Serveren har også en pris i kontekst. Tabular Editor målte i november 2025, at modeling-serveren alene optog 29 procent af kontekstvinduet i en Claude Code-session. Jo mere plads værktøjerne bruger, jo mindre er der til selve opgaven. Slå serveren til, når du skal bruge den, og fra bagefter. Hvordan vi selv arbejder med den, beskriver vi i AI-agenter i Power BI-udvikling.

Hvorfor modellen afgør Power BI MCP-serverens svar

En agent, der kalder Get Semantic Model Schema, får navne, datatyper, relationer og beskrivelser. Det er alt, den ved om jeres forretning. Hedder en kolonne “Amount (LCY)” uden beskrivelse, ved agenten ikke, om beløbet er før eller efter rabat. Hedder et mål “Gross Profit” og har en beskrivelse, der siger, hvad der er trukket fra, kan agenten bruge det uden at opfinde en formel. Det er seriens gennemgående pointe fra AI-agenter på tværs af systemer: agenten bliver ikke klogere end det semantiske lag.

Fire ting i modellen gør forskellen: et stjerneskema med entydige relationer, forretningsnavne i stedet for tekniske, beskrivelser på tabeller, kolonner og measures, og skjulte tekniske felter, så agenten ikke grupperer på en surrogatnøgle. Oven i det kommer Prep data for AI i Power BI med AI data schema, verified answers og AI instructions, som også er i preview. Licenser og modeloprydning har vi gennemgået i Copilot i Power BI: 3 licenstrin og hvorfor den svarer forkert.

Tag et spørgsmål mod oneBC365-modellen: “Hvilke ti kunder har den største bruttoavance i år, og hvordan ser det ud mod sidste år?” Agenten henter skemaet og finder tabellen KPI med measuren KPI Gross Profit blandt salgsmålene, dimensionstabellerne Customer og Calendar og en beskrivelse på hvert objekt. Den skriver en DAX-forespørgsel, der grupperer på kunde og filtrerer på Calendar, og kører den med Execute Query i brugerens kontekst. Den skal ikke selv finde ud af, hvad bruttoavance betyder. Det står i modellen.

Grafikken herunder viser de fire trin i eksemplet.

Et spørgsmål gennem Power BI MCP-server mod oneBC365-modellen i fire trin
Fra spørgsmål til svar: skema, DAX, udførelse i brugerens kontekst og svar. Modellens metadata bærer hvert trin.

Sådan sætter du det op i Power BI

  1. Bed Fabric-administratoren slå tenant-indstillingen “Users can use the Power BI Model Context Protocol server endpoint (preview)” til, og afgræns den til en testgruppe.
  2. Giv testbrugerne Build-rettighed på én semantisk model, ikke på hele workspacen.
  3. Tilføj den remote server i Visual Studio Code med URL’en https://api.fabric.microsoft.com/v1/mcp/powerbi, åbn GitHub Copilot i agent mode, og giv agenten modellens ID, som står i URL’en efter /datasets/.
  4. Stil først spørgsmålet “Hvilke tabeller er der i denne semantiske model?” og derefter tre forretningsspørgsmål, som I kender svaret på fra rapporten.
  5. Til modeludvikling: installér Power BI Modeling MCP i Visual Studio Code, åbn en PBIP-mappe under Git, og start med –readonly, indtil I har set, hvad agenten foreslår.

Hvad Power BI MCP-serverne ikke løser

Begge servere er i public preview. Generate Query kræver Copilot og dermed kapacitet. Dokumentationen for Execute Query og Get Semantic Model Schema nævner ikke et kapacitetskrav, så tjek det i jeres tenant, før I lægger en plan, der kun bygger på Power BI Pro.

Serverne skriver ikke tilbage til Business Central. Den remote server læser, og modeling-serveren ændrer modellen, ikke data i kildesystemet. Komplekse beregninger bliver ikke altid rigtige, når de genereres fra naturligt sprog, og en service principal omgår RLS. Endelig kan en sprogmodel gengive metadata eller data fra modellen i en chatlog, der deles videre. Det er en governance-opgave, ikke en teknisk detalje.

Sådan understøtter oneBC365 det

oneBC365 er bygget efter Microsofts anbefalinger til Copilot: stjerneskema, entydige forretningsnavne som Customer, G/L Entry og Calendar, skjulte tekniske felter og beskrivelser på alle synlige tabeller, kolonner og measures. De 400+ forretningsmål ligger i én tabel, KPI, ordnet i display-mapper, og modellen har cultures for dansk, engelsk og tysk. Det er netop de metadata, Get Semantic Model Schema sender videre til agenten. Modellen er bygget i fire Power Query-lag med samme struktur som en dataplatforms medaljonarkitektur, som beskrevet i Semantisk lag i Power BI, og rapporteringen kører på Power BI Pro.

Løsningen ligger som PBIP med TMDL og PBIR i Git, og kunden ejer koden. Modeling-serveren kan derfor arbejde på filerne, og hver ændring kan gennemgås som en diff, før den publiceres. På services-siden hedder det oneAgent: AI-assisteret vedligeholdelse, hvor I selv arbejder med Copilot og agenter på en AI-klar model eller lader oneBC365 gøre det. Skal agenten slå op i Business Central, er Business Central MCP-serveren den anden halvdel af billedet.

Sådan kommer du i gang

  1. Tjek tenant-indstillingen og jeres kapacitet. Er MCP-endpointet slået til, og har I F2 eller P1, hvis agenten skal bruge Generate Query?
  2. Åbn jeres vigtigste model og tæl beskrivelserne. Hvor mange af de synlige measures har en beskrivelse, der siger, hvad der er med og ikke med? Er det under halvdelen, kommer agenten til at gætte.
  3. Test med tre spørgsmål, I kender svaret på. Sammenlign agentens tal med rapportens. Afvigelser peger næsten altid på et navn, en beskrivelse eller en relation.
  4. Brug modeling-serveren på en kopi under Git. Start med –readonly, lad agenten foreslå beskrivelser, og gennemgå ændringerne som en diff før commit.

Relaterede artikler

Vil I se, hvordan en semantisk model, der er klar til agenter, ser ud på jeres egne tal? Book en demo, eller læs mere om produktet.

Scroll to Top