Almanac
Microsoft/power-biPower Platform

Consultant KB for Microsoft Power BI: semantic models, DAX and modelling, Power Query and dataflows, reports and visuals, the service and workspaces, capacity and performance, embedding and integration, governance and security, ALM and deployment, and licensing, plus cross-cutting decision guides. Scoped to Power BI, with Microsoft Fabric covered where it touches Power BI directly. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power BI release plans, docs repo and product blog, plus the author's own consultant notes.

power-bi/09-alm-and-deployment/feature-power-bi-authoring-mcp-server.md
feature-power-bi-authoring-mcp-server.mdv1 · history
CurrentApplies to BothUpdated 3 days agoSource Microsoft Learn ↗

What it does

An MCP server that lets an AI agent create and change semantic models: tables, columns, measures, relationships, calculation groups, security roles and more, plus running DAX to test what it built. It comes in two forms: a local server that runs on your machine and a hosted (remote) server that Microsoft runs in Fabric.

Key facts

  • Local server is GA. It runs over stdio from the VS Code extension analysis-services.powerbi-modeling-mcp, the npm package @microsoft/powerbi-modeling-mcp, or a standalone executable. It works with models open in Power BI Desktop, PBIP/TMDL files on disk, and Fabric workspace models, and supports transactions and Analysis Services traces.
  • Hosted server is in preview at https://api.fabric.microsoft.com/v1/mcp/powerbi/authoring. Nothing to install, Microsoft updates it, and it works on macOS. It only reaches models in Fabric workspaces, with no Desktop, no local files, no transactions and no traces.
  • Hosted needs the tenant setting Users can use the Power BI Model Context Protocol server endpoint. It signs in with Entra ID as the user; clients that rely on dynamic OAuth client registration can't connect without your own Entra app registration.
  • The local server supports interactive sign-in or a service principal, which makes it the one for CI pipelines.
  • The local server reaches workspace models through the XMLA endpoint, which must be Read Write on the capacity. There's no tenant setting that blocks the local server on its own; you'd have to turn XMLA off.
  • Needs Write (or Build) permission on the model. With Build only, the agent can run DAX but can't change anything.
  • DAX query results are capped at 100,000 rows.
  • Modelling only: it can't change report pages or diagram layouts.
  • The hosted server is stateful, and clients must return the mcp-Session-Id header or the agent reconnects before every operation.

When to use / skip

Use the hosted server for work on Fabric workspace models where nobody wants to install anything, including Mac users. Use the local server for Desktop, PBIP and TMDL work, for service principal automation, or when you need transactions. Skip both for production models without a backup and source control: the agent's changes can be irreversible.

Configuration decisions

  • Hosted or local per scenario. Don't register both in the same client: overlapping tools make routing ambiguous and add token cost to every request.
  • Whether to enable the hosted-server tenant setting, and for which security group.
  • XMLA Read Write on capacities, which also opens the door to every other XMLA tool.
  • Which MCP client and model the team uses. Microsoft recommends a deep-reasoning model, and quality varies a lot by model.
  • For GitHub Copilot Enterprise, an admin has to switch on MCP servers in Copilot, which is off by default.

Gotchas

  • "Reads work, writes fail" is nearly always Build-only permission or XMLA not set to Read Write.
  • Pointing the hosted server at a Desktop file or a PBIP folder fails because it can't see local files. That's by design, not a sign-in problem.
  • Model metadata and query results go into the conversation and to the LLM provider behind your client. That includes data, not only schema.
  • Turning off XMLA to stop the local server also breaks Tabular Editor, DAX Studio and deployment tooling that rely on it.

Consultant notes

  • Back up the model and commit PBIP to Git before any agent session. Make it a rule, not advice.
  • The hosted server is the easier conversation with security teams: no local binaries, Entra sign-in as the user, tenant-setting control. Start there where it fits.
  • Use the best-practice evaluation tools as a quick health check on inherited models. It's a fast way to surface the issues you'd otherwise find by hand.
  • Keep the 100,000-row DAX cap in mind when an agent "validates" a measure. It's sampling, not proving.

Worth revisiting when the hosted server reaches GA

Was this accurate?
Related
XMLA endpoint09-alm-and-deploymentAgentic development with skills for Fabric09-alm-and-deploymentExternal tools09-alm-and-deploymentSemantic model fundamentals01-semantic-modelsPower BI Embedded07-embedding-and-integrationPower BI KB — Features & Changelog_root