The New Tabular Editor CLI That AI Agents Can Run

Most semantic-model work is a series of small, repeatable steps: add a measure, check the model against best practices, fix what the check finds, deploy. Many Power BI developers already do that work in Tabular Editor’s desktop app. It now also ships as a command-line tool, te, where each of those steps is a command, and an AI agent can run commands. An agent with access to a terminal, such as Claude Code, can read the CLI’s help, run a command against your model, read what comes back, and decide what to do next. This article follows one deliberately messy model through that loop: a new measure written as a C# script, a Best Practice Analyzer run, two rounds of automatic fixes, the diff that shows every change, and a deploy to a workspace.

One request becomes several commands. The agent reads each result before it picks the next one.

The example is a sales model built to fail a best-practice check: one Sales fact table and six dimensions, 70 columns and 14 measures. Nothing in it has a description, its measures and most numeric columns have no format string, and every key column is visible. It’s saved as a Power BI project, so the model is a folder of TMDL files in a Git repository. The whole project is in the downloads below, along with the C# script.

0:07What the Tabular Editor CLI is

The Tabular Editor CLI comes from the makers of Tabular Editor. It is a single self-contained executable for Windows, macOS, and Linux that works on semantic models: TMDL folders, .bim files, Power BI project folders, or a model already published to a workspace. Its commands cover editing objects, inspecting and searching the model, validating DAX, the Best Practice Analyzer, running DAX queries and C# scripts, deploying and refreshing, and regression tests.

The CLI was built to be run by an agent or by a release pipeline in GitHub or Azure DevOps. Add --output-format json and a command returns its results as JSON a program can read. Each command also ends with an exit code that says whether it worked: te bpa run, for example, exits with 1 when the model has a violation at error level, so an agent or a pipeline can stop on it. And --non-interactive turns off every prompt, so a command that’s missing input fails with an error message instead of waiting.

The CLI runs C# scripts with access to the Tabular Object Model, the same kind of scripts you may already run in Tabular Editor. You won’t write them yourself here: the agent does.

What you need to run it

The CLI is in limited public preview, which runs until November 30, 2026. To download it you sign in with a Tabular Editor account. Tabular Editor recommends against using the preview in production CI/CD pipelines, because commands, flags, and output can still change before general availability.

One feature is Windows-only: --local, which connects to a model open in Power BI Desktop. On macOS and Linux you work on a model folder on disk, or on a model in a workspace.

Give your agent the official skill

Tabular Editor publishes a skill for AI coding agents: a SKILL.md file plus a references/ folder that teach an agent the command families, sign-in, object paths, output formats and exit codes, and the mistakes agents commonly make with the CLI. For Claude Code, copy the te-cli folder into .claude/skills/te-cli/ in your project, or into ~/.claude/skills/te-cli/ for every project. For GitHub Copilot in VS Code, the folder goes in .github/skills/te-cli/. The skill’s docs page covers other agents. Microsoft publishes skills for Fabric and Power BI as well, and the article on Microsoft’s Fabric skills installs them in Claude Code.

0:49Start a model with te init

The simplest thing to ask for is a new model. In an empty folder, the prompt was:

Use Tabular Editor CLI to initialize a new model in this new model folder.

The agent reads the CLI’s own help before it runs te init.

The agent checked te --help, then te init --help, then ran te init on the folder. The result is two files, database.tmdl and model.tmdl: a blank model in TMDL, ready for tables. The same command can also create a whole Power BI project, with the .pbip file and both the semantic model and report folders:

te init ./my-model
te init ./my-model --serialization pbip

--compatibility-level picks the model’s compatibility level. Without it, te init uses the CLI’s Power BI default.

2:00Add a measure with a C# script

The rest of the article works on the messy sales model. The first job is a new measure, and the prompt names the result rather than the code:

Use the Tabular Editor CLI to run a C# script that will sum the total amount column in the sales table and double it. Call it double sales amount.

It’s a silly measure, but any measure works the same way. The agent started by looking at the Sales table to find the column’s real name, Total Amount. It checked the script command’s syntax with --help, wrote the script to a file, and ran it against the model’s definition folder.

The agent checks the column name and the script command’s syntax, writes the script, and runs it.

This is the whole script, double-sales-amount.csx:

// Create a measure that sums Sales[Total Amount] and doubles it.
var sales = Model.Tables["Sales"];
var m = sales.AddMeasure(
    "Double Sales Amount",
    "SUM ( 'Sales'[Total Amount] ) * 2"
);
m.FormatString = "\\$#,0.00";

Model.Tables["Sales"] finds the table, AddMeasure creates the measure from a name and a DAX expression, and the last line gives it a currency format string. The doubled backslash is C#‘s way of writing one backslash in a string, so the format string the model stores is \$#,0.00.

In version 0.7 of the CLI, the safe order is two commands, run from the project folder:

te script --file double-sales-amount.csx --validate
te script --model "./Sales Demo.SemanticModel/definition" --file double-sales-amount.csx --save

--validate compiles the script without loading the model. Without --save, te script runs the script and shows what would change, but doesn’t write anything. With --save, the change goes into the TMDL files, and the command prints what it changed: the new measure, its expression, and its format string.

When a script doesn’t compile, the CLI exits with code 1 and prints the C# compiler’s message as plain text, for example 'Table' does not contain a definition for 'AddMeasur'. That message is precise enough for the agent to fix the script and try again.

Keep scripts out of the model’s own folders. Then the model’s diff contains only model changes, and the script shows up in Git as a file of its own.

3:11Check the model with the Best Practice Analyzer

The Best Practice Analyzer (BPA) checks every object in a model against a set of rules, such as “visible measures should have descriptions” or “hide foreign key columns”. The CLI ships with built-in rules, so you don’t need a rules file to start. The prompt:

Use the Tabular Editor CLI and run the best practice analyzer against the model in the current folder, and tell me what can be fixed.

The agent read te bpa --help and ran the analyzer on the definition folder. In the preview build used here, 38 rules loaded. The run exited with code 1, because one finding was at error level: “Power BI models should use latest compatibility level”. The full table of findings was long, so the agent ran the analyzer again with --output-format json and counted the results by rule.

The Best Practice Analyzer’s findings on the demo model, counted by rule, with fixability.

The model had 240 violations: one error and the rest warnings. Most were about documentation and presentation:

Rule	Violations	Auto-fixable
Translate visible object names	92	No
Visible columns should have descriptions	70	No
Visible numeric columns should have format string	29	No
Visible measures should have descriptions	15	No
Visible measures should have format string	14	No
Hide foreign key columns	11	Yes

The compatibility-level error can be fixed automatically too. The new Double Sales Amount measure is in these counts: it has a format string, so it isn’t among the 14, but it has no description, so it is among the 15. Running the analyzer after the agent’s own work means one pass checks both the model you inherited and the change you just made.

In JSON, each finding names its rule, its severity, the object it applies to, and whether it can be fixed. Version 0.7 of the CLI uses one JSON shape for findings across te validate, te bpa run, te test run, and te query: a summary with the counts by severity, and a findings list. This is one finding, trimmed:

{
  "severity": "warning",
  "code": "TE3_BUILT_IN_VISIBLE_TABLES_NO_DESCRIPTION",
  "objectPath": "Sales",
  "ruleName": "Visible tables with no description",
  "fixable": false
}

The built-in rules are a starting point. You can pass your own rule files, or your organization’s, with -r, and --no-defaults leaves the built-in rules out:

te bpa run --model "./Sales Demo.SemanticModel/definition" -r ./my-rules.json --no-defaults

4:30Auto-fix, and why it takes two passes

te bpa run --fix --save applies each fixable rule’s fix and saves the model. The agent was told to fix the auto-fixable items, and it ran the fix until nothing fixable was left, which took two passes.

Hiding the key columns in pass 1 is what makes pass 2 necessary.

Pass 1 fixed the compatibility level and hid the 11 key columns, taking the model from 240 violations to 207. The compatibility level went from 1600 to 1702, and the key columns got isHidden.

Hiding those columns made a different rule apply to them: “Set IsAvailableInMDX to false” on hidden columns. That rule is fixable too, so pass 2 set isAvailableInMdx: false on the same 11 columns, and the count fell to 196. The totals drop by more than the number of fixes because a hidden column no longer counts against the rules for visible objects, such as descriptions and format strings.

The 196 that remain are all warnings, and none of them can be fixed automatically: descriptions for tables, columns, and measures, format strings, and translations. Those need decisions about what each object means and how it should look. An agent can still help with them, through another C# script, but that’s a job where you check its work closely.

After the fixes, the agent ran te validate, which checks the model’s DAX expressions and relationships, and it reported 0 errors.

Upgrading a model’s compatibility level can’t be undone. The level the rule asks for is the latest one your copy of the CLI knows about, so check that the workspace you’ll deploy to supports it before you deploy.

Read the changes as a diff

Because the model is TMDL in a Git repository, everything the agent did shows up as changed files: database.tmdl for the compatibility level, model.tmdl, and the six table files that hold the key columns.

The Sales table’s diff: the new measure, then the key columns the fixes hid.

In Sales.tmdl, the new measure is three lines:

	measure 'Double Sales Amount' = SUM ( 'Sales'[Total Amount] ) * 2
		formatString: \$#,0.00
		lineageTag: 7e74a63b-918e-48e6-b263-3258a1fcaecb

Further down, each key column gains two lines. This is Sale Date, one of the foreign keys:

	column 'Sale Date'
		dataType: dateTime
		isHidden
		formatString: Long Date
		isAvailableInMdx: false
		lineageTag: 7f4ed934-60cc-55da-9d09-443a16c75b08

The same two lines appear on the other Sales keys and on the key columns of five dimension tables, such as Customer ID in Customer.tmdl and Employee ID in Employee.tmdl. Read the diff, then commit it or discard it. The CLI can also show its own summary before you save: te script and te bpa run --fix accept --diff (the default), --stat, and --name-only.

If your model isn’t in Git yet, Get Your Power BI Reports AI-Ready with GitHub sets it up, and Power BI as Code explains the TMDL files themselves.

6:11Deploy the model to a workspace

The same tool publishes the model. The prompt:

Use the Tabular Editor CLI to publish the model in this folder to the Power BI service, to a workspace called TE CLI Demo.

The agent checked that it was signed in with te auth status, then deployed the definition folder to the TE CLI Demo workspace as a semantic model named Sales Demo. It added --force because a deploy otherwise asks for confirmation, and a prompt would leave a non-interactive agent waiting. After a browser refresh, the model was in the workspace.

The deployed Sales Demo semantic model in the TE CLI Demo workspace.

The deploy command changed in version 0.7. It’s now a dry run by default: it prints the TMSL script it would send, and --execute actually deploys. -s and -d now name the source model, and the target has its own flags:

te deploy --model "./Sales Demo.SemanticModel/definition" --target-server "TE CLI Demo" --target-database "Sales Demo"
te deploy --model "./Sales Demo.SemanticModel/definition" --target-server "TE CLI Demo" --target-database "Sales Demo" --execute --force

Run the first to see what would happen, and the second to deploy. A few more options are worth knowing: --deploy-partitions and --deploy-roles include the model’s partitions and security roles, and the deploy can gate on the Best Practice Analyzer (--fix-bpa fixes violations first, --skip-bpa skips the check). te refresh works the same way as te deploy: a dry run until you add --execute.

7:01What to try first

These are the loop’s commands in version 0.7 syntax, run from the project folder:

Step	Command	Exit code to watch
New model	te init ./my-model	0 on success
Compile-check a script	te script --file <script.csx> --validate	1 when the script doesn’t compile
Run a script	te script --model <folder> --file <script.csx> --save	Non-zero if it fails
Check best practices	te bpa run --model <folder>	1 with any violation at error level (--fail-on warning to stop on warnings too)
Auto-fix	te bpa run --model <folder> --fix --save (twice)	Same as above
Check DAX and relationships	te validate --model <folder>	1 when it finds an error
Deploy	te deploy --model <folder> --target-server <workspace> --target-database <model> --execute --force	Non-zero if it fails

Download the CLI, give your agent the te-cli skill, and point it at a model you know is messy, such as the one in the downloads. Commit first, then ask it to run the Best Practice Analyzer and fix what it can, and read the diff it leaves.

The CLI is one way to let an AI work on a semantic model. Another is an agent editing the model through Microsoft’s Power BI Authoring MCP server, which the MCP server article covers. For the workspace around the model, Automate Fabric and Power BI Admin with Claude Code uses the Fabric CLI to copy reports, check who has access and read refresh history.