There is no shortage of posts about individual AI tools for Microsoft Fabric and Power BI features. Every week brings updates to MCPs, CLIs and the hard part is no longer learning any one of them. It is knowing which tool to reach for, and when.
This weekend I sat down to install them all and get to the bottom of what tool we can use to help our clients building and migrating into Fabric and Power BI. The organizing principal where I wanted to sort tools by the job they do, not the product name they ship under.
Microsoft Fabric and Power BI MCP and CLI
Fabric tooling looks like sprawl until you notice every tool does one of four things. It authors something, it reads or analyzes something, it operates the platform, or it moves something. For that purpose I label them: Author, analyze, operate, migrate.
For me, when I tag a tool with its verb, the sprawl collapses.
The MCP Servers, and What Each Solves
MCP servers are the interactive API surface. They are what the agent calls when it needs to author or inspect something live, inside a working session.
| Server | Job | What it solves when building | Source |
|---|---|---|---|
| powerbi-modeling-mcp | Author | Builds semantic models directly: tables, measures, DAX, RLS, calc groups. This is your authoring hand for the model layer. | npm package, run locally via npx |
| FabricIQ | Analyze | Inspects published Power BI: discovers objects, reads schema, generates and runs DAX. Use it to see what already exists before you change anything. | Remote HTTP endpoint, registered with a bearer token |
| fabric-core | Operate | Platform operations: workspace and item CRUD, permissions, catalog search. This is the hand for provisioning and governance. | Microsoft remote Fabric MCP endpoint, bearer token |
| fabric-mcp-server | Reference | Serves API specs, schemas, and OneLake development detail. Use it when you need the shape of an API, not to change anything. | npm package, run locally via npx |
The CLIs, and Where They Take Over
CLIs are the broad surface. They reach the workloads the MCP servers deliberately leave alone, and they handle the setup that MCP cannot.
| CLI | Job | What it solves | Source |
|---|---|---|---|
Azure CLIaz | Operate | Mints tokens and makes raw Fabric REST calls. Everything else depends on it for auth. | Azure CLI |
Microsoft Fabric CLI fab | Operate | Workspace and item automation across workloads. This is your general-purpose Fabric hand. | Microsoft Fabric CLI (ms-fabric-cli), via pip |
powerbi-desktop | Author | Opens and reloads PBIP projects in Desktop for model and report work. This is also referenced as Power BI Bridge | Ships with Power BI Desktop |
powerbi-report-author | Analyze | Validates PBIR report projects before you publish them. | Power BI CLI tooling from Microsoft |
You are not alone if you feel confused.
I hoped writing this article would force me to get my arms wrapped around these tools. I regularly have to revert back and ask the LLM what tool to use for the task at-hand.
Building Preferences
As a “non-engineer” I spend most of my day in Cursor. I reach for an MCP server when I need to authoring or inspect inside a live session. Connecting Cursor to Power BI bridge is where I got the biggest gains. I explained in plain English what needed to happen to get my dashboard to UAT readiness and watched the LLM work and the Power BI screen flicker.
I typically reach for a CLI for provisioning, automating, or touching a workload that has no dedicated server. Typically, someone in my role does not get to complete these functions outside of a lab, so I didn’t spend a lot of time exploring these functions.
Gotcha Worth Knowing for Cursor
Learnings with Cursor and VS Code. Cursor cannot OAuth into the fabric-core remote MCP. It attempts dynamic client registration; Fabric’s remote MCP does not support it, and you get an incompatible-auth-server error with no Connect button.
The fix is to mint an Azure bearer token with az and inject it into the MCP client config directly, then refresh it before it expires roughly every hour. It is a small script and a scheduled refresh. Nobody documents it, so budget an hour the first time and none after that.
Where Each Tool Helps for Migration
Migration is where the map pays off, because a migration is not one job. It is six, and each phase reaches for a different tool. In my case I built a rubric and assessment of my migration work so I capture knowledge and bring dashboards from automated migration to UAT ready.
Assess and plan first first. Enumerate the source notebooks, jobs, pipelines, and tables, and flag anything with no Fabric equivalent before you commit to a plan. This is fab and fabric-core reading inventory.
The value is not faster code porting. That is the easy part. The value is a workflow that assesses before it acts and validates at every gate. The feedback loop and knowledge captured in these workflows is just as important as the work itself. In my world of migrations, this is the disciplined part of the process that gets skipped under deadline.
Early Success- Real World Migration
Fabric tooling is not hard because any one tool is hard. It is hard because there are too many.
I had a migration estimate of 35 hours and wanted to break down what % was automated and what % would require cleanup. 35 hour estimate is unacceptable in 2026. For reference, the original Tableau dashboard took 60 hours, including the data engineering effort in Snowflake.
With BIChart automating most of the process the Power BI bridge took the wheel and with a dozen turns and 90 minutes, I had a validated dashboard ready to demo for UAT.
I look forward to sharing results in my own Analytics as Code and Agentic adventures with Microsoft Fabric and BIChart.
