Power BI Modeling MCP Server: Natural Language Edits for Semantic Models

The gap between a semantic model and an AI agent

Power BI semantic models are edited through a small number of surfaces: Power BI Desktop, the Fabric workspace UI, Tabular Editor, and the TMDL files inside a PBIP project. None of those surfaces are conversational. If you want to rename forty columns, restructure a date table, or apply a security rule across a model, you either click through a UI or write a script against the Tabular Object Model. The Power BI Modeling MCP Server inserts a local MCP server between an AI agent and the model, so the agent can issue modeling operations as tool calls. The README frames the goal as bringing "Power BI semantic modeling capabilities to your AI agents" and describes two audiences: developers who want natural language to drive modeling changes, and teams building agentic workflows over a semantic model codebase. The second audience is the more interesting one. Because the server works with TMDL and Power BI Project files, an agent can read and write the textual definition of a model rather than only poking at a live instance. That makes the project relevant to anyone who already treats a semantic model as source-controlled code.

What the server actually does, and what it refuses to touch

The scope is deliberately narrow. According to the README, the server "can only execute modeling operations." It cannot modify report pages, and it cannot change semantic model elements such as diagram layouts. So this is not an agent that redesigns your report; it is an agent that edits the model underneath it. Within that boundary the documented capabilities are concrete. It creates and updates tables, columns, measures and relationships. It runs bulk operations across hundreds of objects at once, with transaction support and error handling, which the README lists under bulk renaming, bulk refactoring, model translations and model security rules. It evaluates and applies modeling best practices against a model. It executes and validates DAX queries so an assistant can test a measure or troubleshoot a calculation. And it supports TMDL and PBIP files, which is what enables the agentic workflow claim: an agent can plan and execute modeling tasks across the model's codebase rather than through a single live connection. The architecture is a local stdio MCP server. That matters for two reasons. First, the server runs on your machine, not in a Microsoft-hosted service, so the connection to Desktop or a Fabric workspace originates locally. Second, because it is stdio, it plugs into any MCP client that can spawn a process, which is why the manual installation path is a JSON block rather than a proprietary integration.

Installing it through the VS Code extension or by hand

The recommended path is the Visual Studio Code extension plus GitHub Copilot Chat. You install VS Code, install the GitHub Copilot Chat extension, install the Power BI Modeling MCP VS Code extension from the marketplace link the README provides, then open Copilot chat and confirm that powerbi-modeling-mcp appears in the tool list. There is a trap here worth knowing before you file a bug: the README notes that if the server does not appear, the MCP servers in Copilot option must be enabled in Copilot settings on GitHub.com, and that for enterprise accounts this option is disabled by default and an administrator has to turn it on. The manual path uses npx and requires Node.js. You add a block to your MCP client configuration with type stdio, command npx, and args -y @microsoft/powerbi-modeling-mcp@latest --start. There is also a manual download route: fetch the VSIX from the marketplace gallery URL with a version and target platform, rename the .visx file to .zip, unzip it, and run extension\server\powerbi-modeling-mcp.exe, then register the JSON the console prints. Once the server is registered, you still have to connect it to a model. The README gives three phrasings: "Connect to '[File Name]' in Power BI Desktop", "Connect to semantic model '[Semantic Model Name]' in Fabric Workspace '[Workspace Name]'", and "Open semantic model from PBIP folder '[Path to the definition/ TMDL folder in the PBIP]'". Those are prompts to the agent, not CLI flags, which tells you the connection step is itself a tool call the model has to get right.

The backup warning is the design, not a disclaimer

The README carries a warning block that is unusually blunt for a Microsoft preview: use caution when connecting an AI agent to a semantic model, because the underlying LLM may produce unexpected or inaccurate results leading to unintended changes, and always create a backup of your model before performing any operations. There is a second warning about data: LLMs might expose sensitive information from the semantic model, including data or metadata, in logs or responses, so chat sessions should be shared carefully. Read those two together and the shape of the risk becomes clear. The server gives an agent write access to a model definition and read access to its contents, and the failure modes are wrong edits and leaked metadata. The transaction support mentioned for bulk operations limits blast radius within a batch, but it does not protect you from a batch that was conceptually wrong. There is a third constraint that is easy to miss: the README states the AI model you select directly influences response quality, and recommends a deep-reasoning model such as GPT-5 or Claude Sonnet 4.5. That is an admission that the tool's usefulness is bounded by the model driving it. A weaker model with write access to a semantic model is not a cheaper version of this workflow; it is a different risk profile.

Where the documentation stops

The README is a getting-started document, not a reference. It does not publish a tool list, so you cannot see from the supplied material which modeling operations are exposed as individual MCP tools versus folded into a generic execute path. It does not document the transaction semantics beyond the phrase "transaction support and error handling," so it is unclear whether a failed bulk operation rolls back fully or partially, and whether that behaviour differs between a Desktop connection and a Fabric workspace connection. It gives no error catalogue, no rate or size limits, and no statement about concurrent connections to the same model. The example scenarios table is truncated in the material available, so the range of documented prompt patterns is narrower than the feature list implies. None of this is fatal for a public preview, and the README says plainly that implementation may significantly change before general availability. But it does mean that adoption right now is an evaluation, not a commitment. If you need to know exactly what a tool call will do before it runs, the current documentation will not tell you.

How this differs from scripting the Tabular Object Model yourself

The obvious alternative is a PowerShell or C# script using the Tabular Object Model, or a TMSL script executed against the model, or editing TMDL by hand in a PBIP folder. The difference is not capability, it is the interface. A TOM script is deterministic: you write the exact rename, you run it, you get the same result every time, and you can review the diff before it executes. The MCP server replaces that with an agent that interprets intent, and the README's own warnings acknowledge the interpreter can be wrong. What you buy in return is the ability to express a change you have not fully specified, which is genuinely useful for exploratory work such as evaluating best practices against a model or probing a DAX measure you do not understand yet. The honest framing is that this is a drafting tool layered on top of an editing surface you should still control. If your team already has a TOM script pipeline with review gates, the MCP server does not replace it. It sits earlier in the process, where you are still deciding what the change should be.

Licence, maintenance and what a preview costs you

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence and it is the same one Microsoft uses across many developer tools, so there is no licensing obstacle to embedding the server in an internal workflow. The practical cost is not the licence, it is the preview status. The README states the project is in Public Preview and that implementation may significantly change prior to General Availability, which means tool names, configuration keys and the connection prompt patterns you build habits around can move. No releases were retrieved from the repository metadata, so there is no published changelog to diff against; the README's manual download instructions reference a specific version (0.1.9) as an example, which suggests versioned VSIX builds exist even though the release feed did not surface them. The npx path pins to @latest, so a manual install and an npx install can silently diverge. If you standardise on this, pin the version in your MCP client config rather than tracking latest, and treat every upgrade as a change that needs the same backup discipline as the first run. Nothing here is legal advice; if you redistribute the server, read the MIT text in the repository.

Editorial conclusion

Adopt it if you already edit TMDL or PBIP files by hand and want an agent to draft table, measure and relationship changes you will review before committing. Do not point it at a production Fabric semantic model as a first experiment, and do not expect it to touch report pages or diagram layouts, because the README states it cannot. Verify three things first: that your MCP client lists powerbi-modeling-mcp as an available tool, that the server version you registered matches the VSIX or npm package you intended, and that you have a backup of the model you are about to connect to.

Official sources

1. Issues
2. License: MIT
3. microsoft/powerbi-modeling-mcp on GitHub
4. README