First Steps with the Power BI MCP Modeling Server
After looking at the installation process and the available configuration parameters, it’s now time to get hands‑on. In this third part, we’ll walk through two practical scenarios that demonstrate how to work with the MCP Server in a Power BI modeling context.
Review
Already in Part 1, we looked at how to connect to the MCP server.:

Create Tables & Columns
As always, meaningful business requirements are the foundation. Typically, these would be documented in a Markdown file. For this example, however, we’ll simulate a pair‑programming session with the MCP Server.
The prompt I used was:
Can you suggest two new dimensions which are missing in the data model.
Write it into the model's TMDL files (under \definition\tables). Work only on the definitions — do not query or execute against the data.
Requirements:
- The new dimensions need to be a fit for the exisiting data model
- Load example data to the dimensions
- Set the correct relationships to the fact table
- Place the corresponding key of the dimension into the fact table
Before excecuting, tell me which dimensions you propose so I can confirm you picked the right ones
After executing the prompt I am getting the following response back from github copilot.

In a real‑world scenario, I would never let an agent decide which dimensions belong in a semantic model — that remains a business decision. But for demonstration purposes, it’s interesting to see how far the agent can reason on its own.
After running the prompt, the agent implemented the changes and provided a validation summary.
Please implement your change and validate it afterwards if you have done the right thing.

A key detail: Do not save the opened file. Close it instead. When reopening, Power BI will typically prompt for a refresh. After refreshing, the two new dimensions appear in the model.
New Dimensions
At that point, you can clearly see that the two new dimensions have been added to the model.

Of course, new dimensions alone don’t make a model useful. Without measures, you can’t build meaningful visuals. So the next step is to create DAX measures that leverage the new dimensions.

Creating measures
Again, in practice, measure requirements should be defined upfront — not invented by an agent. But for this example, I used the following prompt:
Add two DAX measures to this Power BI semantic model that uses these two new dimensions in a logical way.
Write it into the model's TMDL files (under \definition\tables). Work only on the definitions — do not query or execute against the data.
Requirements:
- Measures need to be placed in the correct display folder
- Use the existing date table for date calculation
- Works correctly and it is validated
Before writing, tell me which measures you provide. So I can confirm you can implement them
The agent suggested two measures, which I confirmed. After implementation, it again provided a summary.

After the conformation you will get a new summary of the done things.

As before, the model must be closed without saving and then reopened to validate the changes. The new dimensions worked as expected — but the measures did not.

After two debugging prompts, the measures finally worked. The root cause was a small but impactful error (shown in the original example).


You might expect an agent to get this right on the first try. But I actually appreciate that the debugging process becomes a collaborative experience. Unexpectedly, this turned into a third use case: interactive debugging with an agent.
Conclusion
This marks the final part of the Road to Agentic Development series. But the journey is far from over — I’ll continue exploring this topic and sharing new insights as the ecosystem evolves.