powerbi-orchestrator-mcp

Overview Schema Source Related Servers Discussions Admin

run_dax_regression

Compares DAX query results against a golden baseline file and asserts numerical tolerance, catching calculation regressions during CI/CD changes.

Instructions

Run DAX queries against a baseline and assert regression tolerance.

Use this tool when the user asks to:

Verify that measures or models return consistent results across changes.
Compare live DAX calculation outputs against a golden baseline file.
Check numerical tolerances on calculation outputs during CI/CD.

Args: baseline_path: Path to the JSON baseline file containing expected results. queries_json: Optional list or JSON string of DAX queries to execute. tolerance_pct: Maximum allowed percentage difference between actual and expected numeric values (default: 0.1%). workspace_id: Fabric / Power BI workspace ID holding the dataset. dataset_id: Published semantic model / dataset ID to query. auth_mode: "interactive" or "service_principal". tenant_id: Azure AD tenant ID. client_id: Azure AD client ID. fabric_client: Optional injected FabricClient instance (for testing).

Returns: Dict containing diff summary, passed/failed queries, and variance details. executed=False means no query ran and no verdict is available.

Input Schema

Name	Required	Default
`auth_mode`	No
`client_id`	No
`tenant_id`	No
`dataset_id`	No
`queries_json`	No	[]
`workspace_id`	No
`baseline_path`	Yes
`fabric_client`	No
`tolerance_pct`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.23.0Oct 23, 2026
- addedInput schema / properties / auth_mode / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- changedInput schema / properties / auth_mode / default
```
Previous value: -"interactive"New value: +null
```
- removedInput schema / properties / auth_mode / type
```
Removed value: -"string"
```

Changed7 schema fields changedv1.18.0Oct 17, 2026

addedInput schema / properties / auth_mode

Added value: +{
+  "default": "interactive",
+  "title": "Auth Mode",
+  "type": "string"
+}

addedInput schema / properties / client_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Client Id"
+}

addedInput schema / properties / dataset_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Dataset Id"
+}

addedInput schema / properties / fabric_client

Added value: +{
+  "default": null,
+  "title": "Fabric Client"
+}

removedInput schema / properties / query_executor

Removed value: -{
-  "default": null,
-  "title": "Query Executor"
-}

addedInput schema / properties / tenant_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Tenant Id"
+}

addedInput schema / properties / workspace_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Workspace Id"
+}

Changed1 schema field changedv1.11.0Oct 2, 2026
- removedInput schema / properties / queries_json / type
```
Removed value: -"string"
```
First observedv0.1.0Sep 10, 2026

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It discloses auth modes, a return shape, and the meaning of executed=False, but it does not state whether the operation is read-only, what permissions are required, or whether it has any side effects on the workspace or baseline file.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a one-sentence purpose, followed by focused usage bullets, grouped Args, and a Returns note. It is appropriately sized for nine parameters and does not waste space on repeated schema information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the purpose, use cases, all nine parameters, auth choices, and return behavior, which is strong for a no-annotation tool. It is slightly incomplete because it does not clarify side-effect/read-only behavior or the baseline file structure expected by the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across nine parameters, and the description compensates by explaining every one: baseline_path, queries_json, tolerance_pct with default, workspace_id, dataset_id, auth_mode values, tenant_id, client_id, and fabric_client. This adds substantial meaning beyond the bare schema types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource: run DAX queries against a baseline and assert regression tolerance. The usage bullets clarify that it is for baseline comparison, consistency verification, and CI/CD tolerance checks, which distinguishes it from the generic sibling execute_dax_query.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear when-to-use guidance with three concrete scenarios: consistency verification, comparison against a golden baseline, and CI/CD tolerance checking. It does not explicitly state when not to use it or name execute_dax_query as the alternative for ad hoc DAX execution.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.