Power BI Modeling MCP Server: When AI Stops Suggesting and Starts Building

The chain: you state the intent, the agent decides what to do, the MCP server performs the supported operation against the model, and the result comes back to you to approve.

A business user sends over a familiar list. Three new measures. One calculated column. A relationship that's missing. A change to how gross margin is calculated. And could the date table cover the new fiscal calendar, please.

You know exactly how the next two hours go. Open Power BI Desktop. Find the right table. Write the DAX. Check the naming against the measures already there. Add the relationship, set the cardinality, check the filter direction. Test. Fix. Repeat, five more times.

Now imagine saying this to an AI agent instead:

What happens when an AI agent can work directly with your Power BI model, instead of just telling you what to change?

That's no longer hypothetical. Microsoft's Power BI Modeling MCP Server is a local server that exposes Power BI's modeling operations as tools an AI agent can call. It's in public preview, it's on GitHub under the Microsoft organisation, and it's the most consequential change to Power BI development workflow in years, for reasons that have little to do with how well any model writes DAX.

AI That Answers vs AI That Acts

Every Power BI developer has already used AI the first way.

The difference isn't the quality of the DAX. It's who does the work of applying it, and whether the AI ever sees your actual model.

In the first flow, the AI is guessing. It has never seen your tables, your naming conventions, or the fact that you already have a Date table marked as a date table with a fiscal calendar in it. You are the integration layer: you translate its generic answer into your specific model.

In the second, the agent reads the model first. It knows what the tables are called, which measures already exist and how they're named, and which relationships are in place. Then it makes the change and can run a DAX query to check the result. You review the outcome rather than perform the mechanics.

What MCP Actually Is

The Model Context Protocol is an open standard for connecting AI assistants to external tools and data in a structured way. A useful way to hold it: the AI model is the brain; MCP is the standard socket that lets the brain pick up tools.

Microsoft describes the architecture in three parts, and the names matter because people mix them up constantly:

• Host — the application you're working in, such as Visual Studio Code.
• Client — the component that talks to MCP servers, such as GitHub Copilot.
• Server — the program exposing tools, in this case Power BI's modeling operations.

So MCP is not an AI model, and it is not Copilot. It's the wiring. That's why the same Power BI server can be driven by GitHub Copilot in VS Code, by Claude Code, or by another MCP-compatible client: the tools stay the same, the brain is swappable. Microsoft's own guidance is that the model you choose materially affects the quality of results, and recommends a deep-reasoning model.

One clarification worth making early, because the naming invites confusion: Microsoft has two Power BI MCP servers. The remote one is a hosted endpoint for querying models and getting answers from your data. The local one, the Modeling MCP Server, is the subject of this article, and it's for building and changing models. Query versus build.

What the Power BI Modeling MCP Server Can Do

The server exposes more than twenty groups of modeling tools. Rather than list them all, here's what they cover in practice.

Two design details deserve attention, because they're what make this usable rather than alarming.

First, transactions. Bulk changes can be wrapped and rolled back, which is the difference between an agent that renames two hundred objects and an agent that renames two hundred objects you can undo.

Second, confirmation prompts. The server asks for your approval before the first modification it makes to a model, and before the first query it runs. There's a read-only mode that blocks writes entirely, which is the right way to start. There's also a flag to skip confirmations, which is the right way to end up explaining something unfortunate to your finance director.

Five Real Examples

What this looks like in day-to-day work.

The agent lists the existing measures, infers the pattern (are they Revenue YTD or [Revenue - YTD]?), finds the date table, writes the DAX, creates the measure in the model, and can run a query to confirm it returns something sensible. The naming convention part is the interesting bit: it's reading your conventions rather than inventing its own.

It retrieves the existing definition first, which matters. A generic AI chat would rewrite the measure from scratch and quietly drop whatever edge-case handling was already in there. Reading before writing is the whole point.

"The same as the rest of the model" is only answerable if you can see the rest of the model. The agent can inspect existing relationships and match the pattern, instead of defaulting to whatever a general-purpose chatbot thinks is normal.

Here the agent isn't producing a block of DAX for you to paste. It creates the column through the supported operation, in the right table, with the right data type.

This is the one that tends to surprise people, because it's read-only and immediately useful. The agent can walk the model and report what it finds. Treat the output as a competent second opinion to check, not a verdict.

Microsoft's own documented examples go further still: analysing naming conventions and applying them across a model, generating descriptions for every measure and column as documentation, producing translations of a model, and refactoring related measures into calculation groups. These are exactly the jobs that are conceptually trivial, genuinely valuable, and never get done because they take a week of clicking.

What About Power Query?

This is where precision matters, because it's easy to overclaim. The server is a modeling server, and Power Query sits at the boundary.

What it does expose: named expressions and Power Query parameters (create, update, delete, rename), query groups for organising those expressions, and partitions, which is where a table's source query lives. Microsoft's own example scenario is telling: analyse the Power Query code across all tables, identify the data source configuration, and create semantic model parameters so the source location can be switched easily.

So an agent can read the M behind your tables and work with parameters and expressions as model objects. What it is not is a replacement for the Power Query editor for authoring complex transformations. If your request is "refactor this fifteen-step transformation", that's still your job. If it's "find every table pointing at the old server name and parameterise it", that's squarely in scope.

Before and After

The Business Problem This Actually Solves

Strip away the technology and the case is unglamorous, which is usually a good sign.

What Changes for a Power BI Developer

Not "Power BI developers are no longer needed". That prediction has been wrong every time it's been made about every tool.

What changes is where the value sits. Less of the day goes on manually creating each measure, configuring each relationship and hunting through the model for the object you need. More of it goes on the things that were always the actual job: semantic model architecture, business logic that reflects how the company really works, performance, security, governance, and reviewing changes before they reach anyone who'll make a decision on them.

There's a new skill in the list too, and it's worth naming: directing an agent well. Writing an instruction that carries the right context, knowing what to check in the result, and recognising confident nonsense. That's closer to code review than to prompt engineering.

The value shifts from performing every operation to designing, directing, reviewing and governing the work.

AI Doesn't Automatically Understand Your Business

An agent can read your model's structure. It cannot read your company's mind.

Consider a measure named P4 Contributionmargin YTD CY. A human who's worked there two years knows P4 is a product hierarchy level, that contribution margin excludes allocated overhead by company policy, and that CY means the fiscal year, not the calendar one. An agent sees a string.

This is the uncomfortable, useful part: the quality of agentic development is capped by the quality of your model. Clear names, filled-in descriptions, sensible relationships and documented business rules aren't hygiene tasks any more, they're the context that determines whether an AI agent is useful or actively dangerous in your environment. Teams with a well-documented semantic model get dramatically better results than teams without one, and they get them on day one.

Human in the Loop

The workflow that works looks like this.

1. 1
   Human intent

   A clear instruction, with the context and constraints that matter.

2. 2
   Agent inspects and plans

   Reads the model, works out which operations are needed.

3. 3
   Tool executionMCP

   Supported modeling operations, with your approval on the first write.

4. 4
   Validation

   DAX queries run against the model to check the change behaves.

5. 5
   Human review

   You read what changed and decide whether it's right. Not optional.

6. 6
   Approval and release

   Through whatever source control and deployment process you already use.

Step five is non-negotiable for financial calculations, business-critical measures, relationship changes, and anything touching row-level security. An incorrect measure doesn't announce itself: it renders a number, and someone makes a decision on it. AI should accelerate development, not relocate accountability.

Security and Governance

Microsoft's position here is refreshingly direct, and worth reading carefully before anyone connects this to a production model.

The server runs locally and connects using your existing credentials and permissions. It does not bypass Power BI security: you need write permission on the model, and the agent can only reach what you can reach. Operations follow the same rules as any external tool writing to a model.

But there's a second question that Power BI permissions don't answer. Metadata, schemas and query results the server retrieves are sent to your MCP client, and may be forwarded to whichever AI provider you've configured. Microsoft's summary is the sentence to take to your security team: AI assistance does not expand data access, but it may transmit accessed data to the LLM provider.

Practical implications:

• Governance belongs in your AI data-handling policy and your provider's terms, not only in Power BI settings.
• There's no tenant switch that specifically blocks this server. It connects over the XMLA endpoint, so the only blunt control is disabling XMLA, which also blocks every other tool that relies on it.
• Back up the model before you let an agent touch it. Microsoft says this explicitly, twice.
• Start in read-only mode, and be deliberate about who gets write access and skip-confirmation flags.
• Be careful sharing chat transcripts: they can contain model metadata and data.

What It Does Not Do

• It doesn't touch reports. Microsoft is explicit: the server executes modeling operations only, and cannot modify other Power BI metadata such as report pages or diagram layouts. Your visuals, layouts and bookmarks are out of scope.
• It's in public preview, published as a beta package, and Microsoft warns the implementation may change significantly before general availability.
• Results depend on the model behind it. A deep-reasoning model gives materially better results than a cheap fast one; Microsoft says so directly.
• Clients differ. Not every MCP client implements every safeguard, and Microsoft notes that protections against destructive operations aren't standardised across the protocol.
• An agent can be confidently wrong. The DAX will run. That is not the same as being correct.
• Refreshing data isn't part of it for a model open in Desktop: sending processing commands to a model loaded in Power BI Desktop isn't supported by external tooling.
• It isn't governance. It makes changes faster; it doesn't decide who's allowed to make them.

Do I need PBIP for this?

No, and this trips people up. For the everyday workflow, the agent connects to a model open in Power BI Desktop. Nothing needs converting. Power BI Project files and TMDL are a separate, optional path that matters when you want agentic work to run against source-controlled model files, which pairs naturally with the PBIP and PBIR development workflow. Useful, but not a prerequisite.

FAQ

Is the Power BI Modeling MCP Server the same as Copilot?

No. Copilot is an AI experience. MCP is an open protocol for connecting AI clients to tools. The Power BI Modeling MCP Server is the tool layer that exposes semantic modeling operations. You can drive it from GitHub Copilot in VS Code, or from another MCP-compatible client.

Do we need Power BI Project (PBIP) files to use it?

No. For the basic workflow the agent connects to a model open in Power BI Desktop. PBIP and TMDL files are an additional, optional path for source-controlled development, alongside connecting to a semantic model in a Fabric workspace.

Can the AI agent change our report pages and visuals?

No. Microsoft states the Modeling MCP Server executes modeling operations only. It cannot modify other Power BI metadata such as report pages or diagram layouts. It changes the semantic model, not the report canvas.

Does this give AI access to data it shouldn't see?

The server runs locally and uses your existing credentials and permissions, so it doesn't bypass Power BI security. But metadata, schemas and query results it retrieves go to your MCP client and may be forwarded to the configured AI provider. Microsoft's guidance is that AI assistance doesn't expand data access, but it may transmit accessed data to the LLM provider.

Is it ready for production use?

It's in public preview and Microsoft warns the implementation may change significantly before general availability. Treat it as a development accelerator on models you have backed up, with human review of every change, rather than an unattended process against production.

Wondering whether your models are in good enough shape for this? We can review one and tell you what an agent would struggle with.

The Shift Worth Noticing

The headline isn't that AI got better at DAX. It's that the loop closed. An agent can now understand context, use tools, make changes and validate results inside your modelling environment, rather than producing text you transcribe.

That moves Power BI development away from "open Desktop and perform every task by hand" and toward "describe the change, let the agent work against the model, review what it did, and govern the process." Not for everything, not yet, and not without judgement. But for the repetitive middle of the job, the direction is clear enough to plan for.

The organisations that benefit first won't be the ones with the best prompts. They'll be the ones whose semantic models were already clean, documented and governed enough for an agent to work with safely.

The Power BI Modeling MCP Server is in public preview and moving quickly: tools, flags and behaviours have changed between releases and may change again. Check Microsoft's repository and documentation for the current state before relying on any specific capability described here.

Sources & Further Reading

1. Power BI MCP server documentation, Microsoft Learn
2. What are the Power BI MCP servers? (local vs remote), Microsoft Learn
3. Power BI Modeling MCP Server: tools, setup and limitations, Microsoft on GitHub
4. External tools in Power BI Desktop: data modeling operations, Microsoft Learn
5. Power BI Desktop project semantic model folder (TMDL), Microsoft Learn
6. Semantic model permissions, Microsoft Learn
7. Semantic model connectivity with the XMLA endpoint, Microsoft Learn
8. Model Context Protocol specification