Power BI, MCP, and where AI can really make a difference.

Power BI files are JSON under the hood, like most of the Microsoft Office suite. That means an AI model can read them, understand their structure, and make targeted changes without touching anything outside the scope of what you asked it to do.

The Power BI MCP server exposes that structure to an LLM in a way that is actually usable. The most practical application right now is working with measures. When Stephen asked it to generate measures for a dashboard, the output came back formatted in Tabular Modeling Definition Language, which keeps all the generated content isolated from the rest of the file. If something is wrong, you are not unwinding a mess across the whole report.

Creating pages and visual layouts is a different story. The AI can attempt it, but the results require significant manual cleanup and a clear understanding of the file format to troubleshoot. For now, MCP is most reliable when pointed at the semantic layer rather than the visual layer.

The honest answer from working with these tools across several projects is that AI is reliable for pattern replication and genuinely unreliable for original analysis.

If you give an LLM a set of real examples from work you have already done and tell it to apply the same pattern to similar problems, you can get 25 to 50% time savings. Tell it to build something from scratch with no reference material, and the error rate makes it more trouble than it is worth.

Part of the reason for this is a training data problem. There are enormous amounts of open source code for LLMs to learn from. Enterprise data work, with its specific schemas, business logic, and domain conventions, is mostly private. The models have not seen much of it, unlike Python which is found in countless public code repositories.

The practical implication is that the more context you can give, the better the output. Feed it your actual data dictionary, your existing measures, your documented metrics. If you are working with an undocumented database and need to map relationships across a hundred tables, giving it the actual schema and letting it reason about column names is far more effective than asking it to generate logic from a description.

One approach worth trying for messy datasets: use a large-context model like Gemini, give it read-only access to sample data, and have it randomly sample the data to build a working understanding of the actual schema before generating anything. Be careful with cost if you are querying through something like Databricks or Snowflake where the AI can run costly iterative queries without filters and pruning an analyst would know to use.

The QA use case is where this gets most interesting for teams managing complex or fast-moving dashboards.

The specific problem: a dashboard with around 100 metrics, being iterated on faster than the back end can keep up with. New reports releasing weekly. No reliable way to verify that numbers are still correct after each update.

That handles the data side. For end-to-end testing that includes what Power BI is actually displaying, there is an approach worth exploring that has not been fully built out yet. Power BI can be configured to export scheduled PDF reports. Feed those PDFs into a multimodal model, have it do OCR on the numbers, and compare against expected values.

A separate use case that comes out of working with the Power BI file format directly: report templating at scale.

The idea is straightforward. Build one well-structured report that covers the KPIs, trends, and rankings that 90% of clients want to see. Parameterize the data source. When pitching a new client, scrape their website for brand colors and logo, generate a new data file in the required format, swap in their branding, and produce a branded working report in roughly an hour rather than rebuilding from scratch.

Zach noted a parallel in how Pencil.dev works: a UI layer that stores layout as a JSON blob with embedded SVGs, and an MCP server that gives Claude access to the canvas. The same architecture could apply to Power BI. The report structure lives in an JSON file. An MCP server that exposes that structure to an LLM would make programmatic report generation considerably more practical than the current scripting approach.

For anyone doing new business development in the BI space, this is worth building out. A working branded demo, generated from a client’s own data in their own colors, before you have had a second conversation, changes the sales dynamic.

A few practical notes on the tooling conversation.

Cursor is capable but expensive for serious use. If you are pushing it hard on a real project, it is easy to spend $100 to $200 a day. Their pricing tiers are not well-structured for sustained professional use.

Zed is worth looking at as an alternative. It is free, written in Rust, and model-agnostic. You bring your own API credentials for whichever model you want to use, which means you are not locked into one provider’s pricing. It integrates with Claude, OpenAI, and others.

On the Claude Code side, it is possible to configure it to run against models other than Anthropic’s. Running it against a Chinese open-weights model like GLM47 gives you Claude Code’s context management at a fraction of the cost for tasks that do not require frontier-level reasoning. For workloads where the question is basically “do these two things match” rather than anything that needs real intelligence, that tradeoff can make sense. Running the model locally on a high-end Mac or gaming PC means no data leaves your machine, which matters for client work.

The broader point on model selection: the models have different strengths, the pricing varies significantly by task type, and treating them as non-interchangeable is an expensive habit.