pbi-cli gives Claude Code Power BI, on Windows only in practice

Three names for one tool, and two commands besides

The install instructions use three different identifiers in three consecutive lines. The PyPI distribution is `pbi-cli-tool`, the repository is `pbi-cli`, and the second command in the sequence is `pbi-cli` while the third is `pbi`:

pipx install pbi-cli-tool    # 1. Install (handles PATH automatically)
pbi-cli skills install       # 2. Register Claude Code skills (one-time setup)
pbi connect                  # 3. Connect to Power BI Desktop

The manifest explains the split rather than hiding it: two console scripts are declared, `pbi` pointing at `pbi_cli.main:cli` and `pbi-cli` at `pbi_cli.main_pbi_cli:cli`, so the tool registers both. A third namespace shows up later for custom visuals, `pbi visual import-custom`. None of this is unusual for a young CLI, but it is the first thing that trips someone up, since searching for the repository name on PyPI returns nothing and searching for the package name on GitHub does. There is also a documented shortcut: tell Claude Code to install and set up pbi-cli from the repository URL and it will clone, install, connect and register the skills on its own.

The manifest says OS independent; the README says Windows

Here is a contradiction worth knowing before you plan a pipeline. The package classifiers include `Operating System :: OS Independent`, and `requires-python` is `>=3.10` with tested versions 3.10 through 3.13. The README's requirements line says Windows with Python 3.10+ and Power BI Desktop running. Both cannot be describing the same thing, and the optional dependencies resolve it: there is a `reload` extra that installs `pywin32>=306`, which exists only on Windows, and there is a `preview` extra installing `websockets`. The reason is the architecture. The semantic model layer does direct in-process .NET interop from Python into the desktop application through TOM and ADOMD, which requires a Windows process to interop with. So the classifier is right about the report half and wrong about the tool as a whole, and the safest reading is that pbi-cli runs anywhere the report layer does and only the model layer needs Windows.

Two layers, and only one of them touches your model

The architecture section is deliberately two-part, and the split is about risk as much as about mechanism. The semantic model layer connects to Power BI Desktop in process and can write DAX, create tables and relationships, export and import TMDL snapshots, create row-level security roles and perspectives, and trace query performance. That is live mutation of a running model, which is why it requires `pbi connect` and why the deployment skill is built around taking a snapshot first, with the example prompt being Save a snapshot before I make changes. The report layer does none of that: it reads and writes PBIR, the Enhanced Report Format, as plain JSON files, works with `.pbip` projects, and needs no connection at all. Six of the thirteen skills sit on that side. If you are evaluating this tool, try the report half first, because it cannot damage a model.

No MCP server, stated as a feature

The architecture blurb positions this against the current default. It says the semantic model layer uses direct in-process .NET interop, then adds no MCP server, no external binaries, sub-second execution. All three claims are doing work in a market where the fashionable answer to giving an agent access to a desktop application is to bolt on an MCP server. This design puts the connection inside the same Python process instead of across a protocol boundary, which removes a port, a transport and a second runtime from the picture, and the bundled native libraries ship inside the Python package under `pbi_cli/dlls/` rather than needing a separate install. The cost is the Windows constraint already discussed, and the fact that a dependency on a release candidate is unavoidable: `pythonnet==3.1.0rc0` is pinned exactly, along with `clr-loader`, and the runtime dependencies otherwise total only click, rich and prompt-toolkit.

Version 3.12.0 is titled as a correction

Read the release titles together and they tell a story. The newest, v3.12.0 from 2026-09-18, is described as correcting column and measure bindings and implicit aggregation, which is not the language of a feature release. It is the language of a bug fix, and it implies that the 3.11 line shipped bindings that attached the wrong column or measure. Before that, v3.11.0 and v3.11.1 both landed on 2026-05-04, the second being a custom visual metadata fix, and v3.11.0 introduced Custom Visual Authoring. So the shape is two releases on one afternoon in May, a gap of more than four months, then a binding correction in September. Set against a `Development Status :: 5 - Production/Stable` classifier in the same manifest, that is a claim you should test rather than accept. The last push to the default branch, master, was on 2026-09-30.

The Custom Visuals skill ships an npm allowlist

One skill stands out for its supply-chain behaviour, which is the opposite of the usual agent-skill default. It scaffolds a sibling TypeScript project, iterates against the Power BI Visuals API with `tsc --noEmit` between every change, packages a `.pbiviz` and imports it into your report, driving the SDK like this:

npx --yes powerbi-visuals-tools@^5.6.0 new mygaugevisual
# (Claude edits src/visual.ts + capabilities.json, runs tsc --noEmit until clean)
npx --yes powerbi-visuals-tools@^5.6.0 package
pbi visual import-custom dist/mygaugevisual.1.0.5.pbiviz --replace

The hygiene details are the interesting part. Node and `pbiviz` are auto-installed on first run but only with your consent, the SDK is pinned to a known-good version, the TypeScript project is kept as a sibling of the `.pbip` so it cannot contaminate your report files, and dependencies run under a curated npm allowlist covering D3, Lodash and date-fns, with anything off that list needing explicit approval. An agent that installs packages on your machine, without a list, is a problem. This one ships the list.

pipx, pip, and a PATH problem only Windows has

The `pipx` recommendation is not a style preference, it is a workaround. The README notes that on Windows, `pip install` often places the `pbi` command in a directory that is not on your PATH, and gives you a one-liner to find where it went:

python -c "import site; print(site.getusersitepackages().replace('site-packages','Scripts'))"

You add the printed path to your system PATH and restart the terminal. pipx avoids the problem entirely, which is why it is the documented first choice. Elsewhere the ergonomics are good. Configuration is three files under `~/.pbi-cli/`: `config.json` for the default connection preference, `connections.json` for named connections, and `repl_history`, the last of which tells you the tool has an interactive REPL backed by prompt-toolkit. The seven model-layer skills cover DAX, modeling, deployment, security, documentation, partitions and diagnostics, each with the prompt you would type and what Claude then does, and the six report-layer skills cover reports, visuals, pages, themes, filters and custom visuals.

Editorial conclusion

Adopt pbi-cli if your Power BI work happens on a Windows machine with the desktop application open, and you want an agent to write DAX, build star schemas, snapshot models and author custom visuals against your own semantic model. Do not adopt it expecting a cross-platform tool, since the manifest claims OS independent while the model layer needs in-process .NET interop and the reload extra is pywin32. Verify first which of the two layers you actually need, because the report half reads and writes PBIR JSON with no connection at all and is the part you can try safely.

Frequently asked questions

Official sources

1. License: MIT
2. MinaSaad1/pbi-cli on GitHub
3. Project website
4. README
5. Releases