Sales Data → Model → Report: A Live Session with Power BI MCP and Copilot

The AI-assisted Power BI landscape has grown fast, and it is easy to conflate tools that behave very differently. To keep things focused, this post is a walkthrough of one real session using two specific tools — and nothing else.

I will come back to some of these separately. For this post, the focus is a single project taken end-to-end.

Setup: configuring Claude Desktop for the Power BI Modeling MCP Server

Before any of the session below is reproducible, Claude Desktop has to be told where the Power BI Modeling MCP Server lives on your machine. This is done once, by adding an entry to Claude Desktop's configuration file. It takes about ten minutes end-to-end.

Prerequisites

• Windows 10 or 11 — required for the local Desktop connection. The server can run on macOS/Linux, but only against Fabric workspaces or TMDL files.
• Power BI Desktop installed, with the .pbix or .pbip file you want to work on open.
• Visual Studio Code installed — used here just to install the MCP server extension. You do not need to use VS Code as your AI client.
• Claude Desktop installed and signed in.

The five steps

1. Install the Power BI Modeling MCP Server VS Code extension

   Open VS Code, go to the Extensions panel, and search for "Power BI Modeling MCP". Install the extension published by analysis-services. This is Microsoft's official distribution mechanism for the server binary — even though we are wiring it into Claude Desktop, VS Code is the delivery vehicle.

2. Locate the server executable

   After the extension installs, the server binary lives at:

   %USERPROFILE%\.vscode\extensions\ analysis-services.powerbi-modeling-mcp-<VERSION>-win32-x64\ server\powerbi-modeling-mcp.exe

   Open File Explorer, navigate to that folder, and copy the full path to powerbi-modeling-mcp.exe (right-click → Copy as path). The <VERSION> segment will be whatever version was installed — for example, 0.4.0.

3. Open the Claude Desktop config file

   In Claude Desktop, open Settings, go to the Developer tab, and click Edit Config. This opens the folder containing claude_desktop_config.json. Open that file in a text editor. Alternatively, browse directly to:

   %APPDATA%\Claude\claude_desktop_config.json

   If the file does not exist yet, create it with an empty JSON object: { }

4. Add the MCP server block

   Paste the following block into the file. Replace the command value with the path you copied in step 2, and make sure every single backslash is doubled (\\ in JSON):

   { "mcpServers": { "powerbi-modeling-mcp": { "command": "C:\\Users\\<USERNAME>\\.vscode\\extensions\\analysis-services.powerbi-modeling-mcp-<VERSION>-win32-x64\\server\\powerbi-modeling-mcp.exe", "args": ["--start"], "type": "stdio" } } }

   If you already have other MCP servers configured, just add powerbi-modeling-mcp as another entry inside the existing mcpServers object.

5. Restart Claude Desktop and verify

   Fully quit Claude Desktop (not just closing the window — check the system tray) and reopen it. A tools indicator should appear near the chat input, showing that the powerbi-modeling-mcp server is loaded.

Once the tools indicator is visible, open your .pbix file in Power BI Desktop, and you are ready for the session below.

The project

I started with sales datasets from a set of branches — the kind of thing every retail or distribution BI developer has sitting in a .pbix file: transactions, branch info, geography, revenue figures, but no proper date table and no relationships tied to a calendar. I wanted to see whether I could take this from raw tables to a first-draft dashboard using AI on both ends of the workflow — MCP for the model, Copilot for the report.

Step 1 — Connecting Claude to the Desktop file

With the .pbix open in Power BI Desktop, I asked Claude (via the Power BI Modeling MCP Server) to connect to the model. The server discovers the local Analysis Services instance behind Desktop and attaches to it. From that point on, Claude could see everything live — tables, columns, relationships, measures, roles — the full semantic model surface.

This is only one of three connection modes the MCP server supports (the others being a Fabric workspace via XMLA and a PBIP folder on disk), but it is the fastest way to start when you are already working locally.

Step 2 — Describing the tables

Before touching anything, I asked Claude to describe what it was looking at. This is a small habit that pays off. The agent produced a written inventory: tables, key columns, apparent grain, cardinalities, and — usefully — any modeling smells it could spot. It flagged the absence of a proper Date table straight away and correctly identified which columns in the sales table were candidates for a relationship to it.

This step doubles as a sanity check for me and as context for the model. Everything Claude does afterwards is grounded in this description, and it makes later prompts noticeably shorter.

Step 3 — Building a Calendar table and wiring relationships

I then asked Claude to create a Calendar table and set up the relationships to the fact table. Because the MCP server exposes the Tabular Object Model directly, this is not a "here is some DAX, paste it in" suggestion. Claude actually created the table (with the date range inferred from the fact table), added the standard columns (Year, Quarter, Month, MonthName, YearMonth, WeekOfYear, and so on), marked it as a date table, and created the active relationship to the fact table's date column.

A few things stood out:

• The grounding from Step 2 turned this into a near one-shot prompt. Claude already knew the fact table's date column and its range.
• The first time Claude tried to modify the model, the MCP client asked me to confirm the write — the elicitation step is on by default, and I like keeping it on for anything live.
• Everything persisted straight into the model open in Desktop. No copy-paste, no external script. A quick refresh in Desktop and the new table and relationships were there.

At this point I had a properly modeled dataset — Calendar table wired in, ready for time-intelligence. This is exactly what the MCP server is designed for, and it is where it shines.

Step 4 — Handing off to Copilot in Desktop for the report

This is where the tool boundary matters. The Power BI Modeling MCP Server, by design, cannot build report visuals. It is a modeling tool, full stop. If I had stayed in Claude I could have added measures, refactored the model, or generated documentation — but I could not have laid out a single chart.

So I closed the MCP session and turned to Microsoft Copilot inside Power BI Desktop. I asked it for a report showing:

• Sales KPIs
• Sales by branch
• Sales by geographical location
• Sales by revenue
• Total sales

Copilot drafted the page: KPI cards for total sales and headline metrics, a bar chart broken down by branch, a map visual for the geographical breakdown, a revenue chart, and a total-sales card. It made reasonable choices about visual types, laid them out on the canvas, and — importantly — connected them to fields that now included the Calendar-driven ones we had set up in Step 3, so time context worked properly.

This is the half of the workflow MCP simply cannot cover today.

Reflections on the two halves

A few things I took away from running the same project across both tools. First, the shape of the split:

• They cover different halves of the loop. MCP finished the model in a few minutes; Copilot in Desktop got me to a first-draft report shortly after. Neither could have done the other's job.
• The model behind the client matters more than the client itself. For the MCP half, Claude Sonnet gave me clean, one-shot results. Microsoft's own guidance notes that a deep-reasoning model is what makes the Modeling MCP work well; lighter completion models will call the tools but plan worse. The same MCP server driven from VS Code + GitHub Copilot is capable too — but be intentional about which model you point at it, because the out-of-the-box defaults are not equivalent.
• Desktop and Service both matter, and MCP crosses them. The local MCP server can attach to a Desktop model, a Fabric workspace model via XMLA, or PBIP TMDL files on disk. That gives MCP an unusually wide reach for a modeling tool.

The working pattern I have landed on

Neither tool is trying to replace Power BI — they are both trying to remove the parts of the workflow that used to be pure clicking. In this session, together, they removed enough of it to be genuinely worth the setup.