microsoft / fabric-cli

fabric-cli-core covers the filesystem-style surface of fab — ls, cd, mkdir, cp, mv, and rm against workspaces, notebooks, lakehouses, and other Fabric items, plus OneLake file upload and download, table load and optimize, job run and schedule, and direct REST calls with JMESPath filtering. fabric-cli-powerbi narrows to Power BI itself: refreshing semantic models, running DAX queries, managing reports, and troubleshooting failed refreshes and gateways, all still issued through fab rather than a separate Power BI-only tool.

This is for people who already work inside Microsoft Fabric or Power BI and would rather script workspace operations than click through the portal for each one. fab itself needs a Python 3.10–3.13 install (pip install ms-fabric-cli) and a Fabric tenant to point at; nothing here does anything against a Fabric-shaped resource that doesn't exist.

READ THE FULL ANALYSIS＋

The two skills carry different setup expectations. Our check flags fabric-cli-core as needing a live Fabric account before it can do anything — fab auth login, a service principal, or a managed identity — while fabric-cli-powerbi is flagged only as needing the fab binary installed locally, on the assumption that authentication is already sorted out by the time someone reaches for Power BI-specific commands.

Authentication has four separate paths, and the skill inherits all of them from fab itself: interactive browser login, a service principal with a client secret, certificate, or federated token, a system- or user-assigned managed identity, and plain environment variables for headless automation. Which one applies depends entirely on where the agent is running, not on which of the two skills it's using.