Co-authored by

What Claude Actually Automates in Power BI

Quick answer: Claude automates the file layer. Reports and semantic models saved as a Power BI Project are plain text: PBIR JSON for the report, TMDL for the model. An agent edits those files directly. It does not drive the Power BI Desktop interface.

This is the distinction that decides whether AI-assisted Power BI development is a demo or a delivery process. A chat assistant produces an answer you paste somewhere. An agent editing PBIR produces a diff: a set of changed files with a before and an after, which can be reviewed, rejected, and deployed by something other than a person clicking Publish.

Microsoft shipped the tooling for the second version in mid-2026, and it names Claude Code as a supported client. What Microsoft did not ship is the surrounding process. Its entire published guidance on source control for agent-generated reports is one sentence: "Commit a baseline before you allow the agent to modify PBIR files so you can revert changes." That is rollback. It is not review, and it is not deployment.

This post covers the part that sits between them. It assumes you already have Claude connected to Power BI through MCP and that you have seen what Claude does with DAX. The question here is what happens to the files afterwards.

Which Tools Does Microsoft Ship for Agentic Power BI Development?

Quick answer: Five layers: the Modeling MCP server for semantic models, the remote MCP server for querying them, the Report Authoring skill for PBIR files, the Desktop Bridge for visual verification, and the Report Design and Report Planner skills for greenfield work. All are in preview as of August 2026.

The Power BI Report Authoring skill overview, published 3 June 2026, sets out the division of labour:

The Report Authoring skill does not touch semantic models. Microsoft is explicit: use it "when an agent needs to create or modify the report layer," and for "tables, columns, measures, DAX" use the Modeling MCP server instead.

The skill works only with PBIP files. A .pbix is opaque to it. The conversion is a Save As in Power BI Desktop, and it is not scriptable. Microsoft's own FAQ answers "Can I convert PBIX into PBIP and vice-versa programmatically?" with a flat "No."

Installing the skills in Claude Code

The skills ship in microsoft/skills-for-fabric, Microsoft's first-party, MIT-licensed catalogue, as a plugin called powerbi-authoring. In Claude Code, add the marketplace first, then install the plugin:

/plugin marketplace add microsoft/skills-for-fabric
/plugin install powerbi-authoring@fabric-collection

That brings in five skills: powerbi-report-authoring, powerbi-report-design, powerbi-report-planning, powerbi-report-management and semantic-model-authoring. It also registers the Modeling MCP server for you, which is otherwise a manual step. The separate fabric-skills bundle covers the wider platform (Lakehouse, Spark, KQL, Eventstreams, Dataflows Gen2 and warehouse work) and does not include the Power BI plugin.

The skill drives two command-line tools, which install from npm and need Node.js 20 or later:

npm install -g @microsoft/powerbi-report-authoring-cli@latest @microsoft/powerbi-desktop-bridge-cli@latest

Most Fabric operations authenticate through the Azure CLI:

az login
az account get-access-token --resource https://api.fabric.microsoft.com

The skill is "optimized for GitHub Copilot CLI with cross-tool compatibility for VS Code Copilot, Claude Code, Cursor, Codex/Jules, and Windsurf." Read that as written: the primary target is Copilot CLI, and the Claude Code path is supported rather than tuned.

The loop Microsoft describes

Microsoft's documented end-to-end flow runs in five steps: use the Modeling MCP server to make sure the semantic model has what the report needs; use the Report Authoring skill to edit PBIR files; run validate-report to catch structural problems; use the Desktop Bridge to reload Desktop and capture screenshots; then "delegate review to an independent design-reviewer pass and iterate until both validation and visual checks pass."

The Power BI Desktop Bridge is the piece with no equivalent in ordinary automation. It is a local JSON-RPC 2.0 server running inside a live Power BI Desktop process, exposing methods including bridge.manifest, application.state.get/v1, file.reload/v1 and report.snapshot.capture/v1. It lets an agent look at what it built instead of trusting that valid JSON renders correctly. It is governed by a Preview features checkbox, "Enable external tool access to Power BI Desktop through secure local APIs," which is on by default rather than opt-in. Remote access is not supported: the pipe is local to the machine, each Desktop window gets its own, and only one operation runs at a time.

That loop closes the correctness gap. It does nothing about the governance one, because every step happens on one developer's machine.

What Do PBIR and TMDL Look Like on Disk?

Quick answer: One JSON file per visual, one JSON per page, one TMDL file per table. Almost everything is text and diffable; the exceptions are a binary data cache and four files whose schemas Microsoft has not documented.

Saving as a Power BI Project produces a folder per item rather than a single file:

Project/
├── AdventureWorks.Report/
│   ├── definition.pbir
│   └── definition/
│       ├── pages/
│       │   ├── pages.json
│       │   └── ReportSection1/
│       │       ├── page.json
│       │       └── visuals/
│       │           └── 3a1f9c/
│       │               └── visual.json
│       ├── report.json
│       └── version.json
├── AdventureWorks.SemanticModel/
│   ├── definition.pbism
│   └── definition/
│       ├── model.tmdl
│       ├── relationships.tmdl
│       ├── expressions.tmdl
│       └── tables/
│           └── Sales.tmdl
├── .gitignore
└── AdventureWorks.pbip

Each JSON file declares a public schema, following the pattern https://developer.microsoft.com/json-schemas/fabric/item/report/definition/<fileType>/<version>/schema.json. The full set is published in microsoft/json-schemas, covering visualContainer, page, report, bookmark, semanticQuery, filterConfiguration and the rest. That is what makes agent-generated output checkable rather than merely plausible.

The semantic model side is TMDL, one file per table plus files for relationships, roles, cultures and expressions. TMDL view in Power BI Desktop is generally available; TMDL view on the web is still preview.

What does not diff. Power BI Desktop writes a .gitignore on first save containing exactly two entries:

**/.pbi/localSettings.json
**/.pbi/cache.abf

cache.abf is an Analysis Services backup, the actual cached data, in binary. A repository that has lost that .gitignore is committing data rows into source control.

Four more files are text but out of bounds. Microsoft states that schema details for the report's report.json (the legacy root-level one), mobileState.json, semanticModelDiagramLayout.json and the model's diagramLayout.json "aren't documented," and that "during preview, changes to these files outside of Power BI Desktop aren't supported." An agent that edits them is working without a contract.

The service also enforces hard ceilings on PBIR reports: 1,000 pages per report, 1,000 visuals per page, 300 MB total report size, and 300 MB of resource package files. Generation makes it easier to reach those numbers than hand-authoring ever did.

How Should You Review Agent-Generated PBIR?

Quick answer: As code. The diff is the artefact, and four PBIP-specific mechanics will corrupt it before a reviewer ever reads it — line endings, path length, encoding, and a schema version that is not published.

Microsoft's advice to commit a baseline gets you a working undo. It does not get you a second pair of eyes, which is what actually stops a generated report reaching production with a broken filter.

Set up the mechanics first, because each of these produces a diff that is either unreadable or wrong.

Line endings. Power BI Desktop writes CRLF. Microsoft's own instruction is to configure Git's autocrlf "to avoid problems in your diffs." Skip it and the first commit from a machine with different settings rewrites every line of every file, and the real change disappears inside thousands of phantom ones.

Path length. PBIP explodes a report into nested folders, and Windows caps paths at 260 characters by default. Microsoft's mitigation is blunt: "use a short folder path as the root location for your PBIP." Long table names are the usual cause. This fails at save time, not review time, but it fails during a generation run more often than during manual authoring because agents produce more files at once.

Encoding. Files edited outside Power BI Desktop "should be saved using UTF-8 without BOM." A BOM introduced by an editor or a script breaks the file for Desktop.

Schema versions can outrun the published schemas. As of August 2026, issue #573 in the json-schemas repository, opened 12 May 2026 and still open, reports that visualContainer schema version 2.8.0 is emitted by Power BI Desktop but returns a 404 when fetched. Validation tooling that resolves $schema over the network will fail on files that are perfectly valid. Pin the schema version you validate against rather than trusting the URL in the file.

What to look for in the diff

Once the diff is readable, the review is specific to what these agents get wrong:

• Query bindings, not appearance. Microsoft lists diagnosing "a visual rendering as an error icon or empty frame" and fixing "the underlying queryState or role bindings" as a use case for the skill, which tells you where the failure mode lives. A visual can be structurally valid, pass validate-report, and be bound to nothing.
• Deprecated visual types. Microsoft warns that "some visuals, including Q&A, Bing maps, and filled maps, will be deprecated soon" and recommends not prompting agents to create them. A model trained on years of Power BI examples will reach for them unprompted.
• Legacy versus modern visuals. card and matrix are the old forms; cardVisual and pivotTable are current. Converting between them changes how selector-based formatting applies.
• Filter values. Slicer selections and filter values persist into visual.json as plain text. They are metadata by file type and data by content. A diff can leak a customer name or an account number into a pull request that a wider group can read.
• Unsaved Desktop state. "The PBIR file is the source of truth." If a developer has unsaved changes open in Desktop and asks the agent to iterate, the agent reads the file and silently discards that work.

A useful gate on the pull request runs validate-report, checks the schema, and blocks deprecated visualType values. None of that needs a model; it is a script. The human review is then free to be about whether the report answers the question it was built for.

Can You Deploy PBIP Without Opening Power BI Desktop?

Quick answer: Yes. fabric-cicd, Fabric git integration, or the Fabric item-definition REST APIs all deploy a PBIP folder to a workspace, and all three move metadata only.

Microsoft documents three publishing routes for a Power BI Project: Fabric git integration, the Fabric APIs, and Power BI Desktop's own Publish button. They are not equivalent, and the difference matters beyond convenience.

Desktop Publish moves more than the other two. Microsoft's note is unambiguous: publishing from Desktop "uses a temporary PBIX file," and "unlike other PBIP deployment options that only deploy metadata, this publishing method deploys both the metadata and the local data cache of the semantic model being edited." Deploy from CI and you ship definitions. Deploy from a laptop and you ship whatever that laptop had cached.

fabric-cicd is the path Microsoft documents for automated deployment: an open-source Python library it maintains. pip install fabric-cicd, point it at a source directory, and it sequences dependencies so the semantic model lands before the report that binds to it. Environment differences go in a parameter.yml find-and-replace, which is how the same commit targets a development and a production workspace without editing definitions. It authenticates through the Azure Identity SDK, so a service principal in GitHub Actions or Azure DevOps works.

The item-definition APIs are the layer underneath. POST /v1/workspaces/{workspaceId}/items/{itemId}/getDefinition and the matching update calls take every file as a base64 part:

{
  "definition": {
    "parts": [
      {
        "path": "definition/pages/ReportSection1/page.json",
        "payload": "ewogICIkc2NoZW1hIjogLi4u",
        "payloadType": "InlineBase64"
      }
    ]
  }
}

These are long-running operations: a 202 Accepted with Location, x-ms-operation-id and Retry-After headers means poll, not retry. Reports default to PBIR and semantic models to TMDL. Rebinding a report to a different semantic model is a property of definition.pbir rather than a separate API call.

Three constraints that shape the pipeline

Throttling is a fixed window, not a leaky bucket. Fabric's unified quota model, updated 14 August 2026, gives each identity three independent buckets of 200 calls per minute, evaluated on a 60-second window that refills all at once. Burst through it and you are blocked for the remainder of the window rather than gradually slowed. A deployment that pushes a few hundred files as individual calls will hit this; batch the parts into one definition call. Note also that a 429 carrying CapacityLimitExceeded is a different problem from one carrying RequestBlocked. The first needs more capacity, not a retry.

Service principals need a tenant switch and are not universal. The admin setting "Service principals can use Fabric APIs" must be on. Even then, support is per item type: Microsoft's Get Item Definition reference notes support applies "when the item type in the call is supported," so do not assume report behaviour matches semantic model behaviour. The Modeling MCP server supports service principals; the remote Power BI MCP server does not, which rules it out of headless CI.

Two things cannot be automated through the Fabric REST API at all. Microsoft lists both as PBIP limitations: it is not possible to get or set row-level security role members, and it is not possible to get or set incremental refresh partitions. On a governed deployment those are exactly the two settings you would most want in code, so a pipeline claiming to be fully automated is either not using RLS or not telling the truth.

Git integration supports reports and semantic models in preview, through Azure DevOps or GitHub. Two exclusions matter before you plan around it: reports connected to Azure Analysis Services or SQL Server Analysis Services models, and reports depending on a semantic model in My Workspace.

What in This Stack Is Still Preview?

Quick answer: Nearly all of it. PBIP itself was still labelled preview in Microsoft's documentation revised on 18 August 2026, along with PBIR, the Report Authoring skill, the Desktop Bridge, both Power BI MCP servers, and git integration for reports.

Worth being precise about, because several widely-shared posts have called PBIP and PBIR generally available in Q3 2026. Microsoft's Power BI Desktop projects overview still opens with "Power BI Desktop projects is currently in preview" and names no GA date. Saving as PBIP requires ticking "Power BI Project (.pbip) save option" under File → Options and settings → Options → Preview features.

The Fabric CLI is the exception. ms-fabric-cli reached general availability in April 2026 and is on version 1.7.0 as of 19 August 2026.

Three consequences follow for anything you build now.

The format will change under you, in one direction. Microsoft states that when PBIR reaches GA it becomes the only supported format and PBIR-Legacy stops being supported. Conversion from PBIR-Legacy to PBIR is one-way and cannot be rolled back, though a backup is written.

Undocumented files stay undocumented until GA. The four files listed earlier are off limits for external editing for as long as preview lasts.

Third-party tooling carries its own clock. Tabular Editor's CLI, which includes a pbir-cli for programmatic PBIR editing, is in limited public preview and its build stops working on 30 September 2026; the vendor recommends against production CI/CD use until then. semantic-link-labs is a Microsoft repository but labs-grade, supported through GitHub issues rather than an SLA.

None of that is a reason to stay away. It is a reason to keep the agent's output in your repository, where you control it, rather than in a workspace where a format migration reaches it first.

What Leaves Your Tenant When an Agent Builds a Report?

Quick answer: PBIR and TMDL are metadata: table names, measure expressions, layout, and any filter values baked into the report. Screenshots captured through the Desktop Bridge are something else entirely: rendered report data.

For regulated work in the UAE and Saudi Arabia this is the question that decides whether the pipeline is usable, and it deserves a more precise answer than "AI sees your data" or "it's only metadata."

Model and report definitions are metadata, and metadata is disclosive. A TMDL file carries table names, column names, DAX expressions and relationships. That is a schema, and for a bank or a government entity a schema is frequently confidential even when no row of data is attached. Treat it as you would treat source code leaving the building, because that is the same category of thing.

Screenshots are data. A report.snapshot.capture call returns a picture of a rendered report — real numbers, real customer names, whatever the visuals show. If those images go to a model for a visual review pass, actual data has left the tenant, not metadata. Microsoft's Desktop Bridge documentation covers the mechanics and does not address this; it is a conclusion you have to draw yourself, and it is the single most overlooked step in the loop. Run visual verification against a development semantic model with non-production data and the problem disappears.

Anthropic's commitment is specific and worth quoting accurately. Per Anthropic's API data retention documentation, retained data "is never used for model training without your express permission," and Zero Data Retention is available to qualifying enterprise customers. That is a stronger commitment than most enterprise reviewers assume, and it is also not the same as data never leaving your control, a distinction worth putting in front of a security team in writing rather than paraphrasing.

One governance gap is Microsoft's, not the agent's. Sensitivity labels are not supported with Power BI projects. A report that carries a Microsoft Purview label in the service loses it on the round trip through PBIP. For an organisation whose PDPL or NDMO controls depend on labelling, that is a hole in the process that no amount of careful prompting closes. It is also an argument for deploying through git and the APIs, where the label is applied in the service and never round-tripped.

Region availability constrains where the deployed content can live. Microsoft's Fabric region availability list, revised 19 August 2026, names three Middle East regions. UAE North supports all Fabric workloads. UAE Central and Qatar Central are marked "Power BI only region," so no F SKU capacity. No Saudi Arabia region appears in the table at all. For an in-region Fabric capacity in the Gulf, UAE North remains the only answer, the same conclusion reached in our Power BI data residency guide, and unchanged by anything in the agentic stack.

Frequently Asked Questions

Q: Can Claude build a complete Power BI report?

Yes, within limits. With Microsoft's Power BI Report Authoring skill installed, Claude Code can create and modify pages, visuals, filters, slicers, bookmarks, themes and formatting by editing PBIR JSON directly, then verify the result by reloading Power BI Desktop and capturing a screenshot through the Desktop Bridge. It cannot work on a .pbix file. The project must be saved as PBIP first, which is a manual Save As in Power BI Desktop. It also does not build the semantic model; tables, columns, measures and DAX are handled by the separate Power BI Modeling MCP server.

Q: What is PBIR in Power BI?

PBIR (Power BI Enhanced Report Format) is the text-based format a report takes inside a Power BI Project. Instead of one opaque file, the report becomes a folder tree under definition/ with one JSON file per page and one per visual, each declaring a public JSON schema. That structure is what makes reports diffable in git and editable by tooling other than Power BI Desktop. As of August 2026 PBIR and PBIP are both still in preview.

Q: Is Power BI Project (PBIP) generally available yet?

No. Microsoft's Power BI Desktop projects documentation, with page metadata dated 18 August 2026, still states that "Power BI Desktop projects is currently in preview," and gives no GA date. Several third-party articles claim general availability in Q3 2026; that is not supported by Microsoft's own documentation. Saving as PBIP still requires enabling the "Power BI Project (.pbip) save option" under Preview features in Power BI Desktop.

Q: How do you install Microsoft's Power BI skills in Claude Code?

The skills ship in the MIT-licensed microsoft/skills-for-fabric repository as a plugin. In Claude Code, add the fabric-collection marketplace through the /plugin command, then run /plugin install powerbi-authoring@fabric-collection. That installs the Report Authoring, Report Design and Report Planning skills together. Most Fabric operations then authenticate through the Azure CLI with az login. Microsoft describes the skills as optimised for GitHub Copilot CLI with cross-tool compatibility for Claude Code.

Q: Can you deploy Power BI reports to Fabric from a CI/CD pipeline?

Yes. fabric-cicd, an open-source Python library maintained by Microsoft, deploys PBIP source directories to a Fabric workspace, sequences semantic models ahead of the reports that depend on them, and parameterises workspace and lakehouse identifiers per environment through a parameter.yml file. It authenticates with a service principal via the Azure Identity SDK, so it runs unattended in GitHub Actions or Azure DevOps. Two things stay manual: row-level security role members and incremental refresh partitions cannot be set through the Fabric REST API.

Q: Does the Power BI Modeling MCP server work with reports?

No. The Modeling MCP server is scoped to semantic models: creating and updating tables, columns, measures and relationships, validating DAX, and editing TMDL. It does not author report pages or visuals. That is the Report Authoring skill's job, and the two are separate installations. The remote Power BI MCP server is different again: it queries data and generates insights, and it authenticates only as a signed-in user, so it cannot be used from an unattended pipeline.

Q: Is it safe to let an AI agent write Power BI files for regulated data?

It depends on which step you mean. Editing PBIR and TMDL exposes metadata: table names, DAX expressions, layout, and any filter values saved into the report. Many GCC financial and government entities already classify that as confidential. Screenshot verification through the Desktop Bridge is a different matter, because a screenshot contains rendered data rather than metadata; run that step against a development model with non-production data. Note also that sensitivity labels are not supported with Power BI projects, so a Purview label does not survive a round trip through PBIP.