powerbi-orchestrator-mcp

Overview Schema Source Related Servers Discussions Admin

execute_dax_query

Run DAX queries against published Power BI semantic models or Fabric datasets to inspect measures, KPIs, and table rows, or test row-level security by impersonating a user.

Instructions

Execute a DAX query against a published Power BI semantic model / Fabric dataset.

Use this tool when the user asks to:

Run, evaluate, or test a DAX query against a live dataset in Power BI or Fabric.
Inspect actual business data, measure outputs, KPI calculations, or table rows.
Verify Row-Level Security (RLS) filters by simulating a specific user principal name.

Args: workspace_id: Fabric / Power BI workspace ID (UUID). dataset_id: Published semantic model / dataset ID (UUID). dax_query: The DAX query expression (e.g. "EVALUATE TOPN(10, 'Sales')" or "EVALUATE ROW("Total", [Total Sales])"). impersonated_user_name: Optional User Principal Name (UPN) to test RLS rules as that user. auth_mode: "interactive" (default, browser login) or "service_principal". tenant_id: Azure AD tenant ID (required for service_principal). client_id: Azure AD client ID (for service_principal). max_rows: Maximum number of rows returned to the caller (default 1000, hard ceiling 10000). Prevents bulk extraction of business records into the model context. fabric_client: Optional injected FabricClient instance (for testing).

Returns: Dict containing query execution results with tabular rows, columns, and execution metadata.

Input Schema

Name	Required	Description	Default
`max_rows`	No
`auth_mode`	No
`client_id`	No
`dax_query`	Yes
`tenant_id`	No
`dataset_id`	Yes
`workspace_id`	Yes
`fabric_client`	No
`impersonated_user_name`	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"
```

Changed2 schema fields changedv1.18.0Oct 17, 2026

removedInput schema / properties / client_secret

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Client Secret"
-}

addedInput schema / properties / max_rows

Added value: +{
+  "default": 1000,
+  "title": "Max Rows",
+  "type": "integer"
+}

Addedv1.11.0Oct 2, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations present, the description carries the full burden and does substantially well: it discloses both auth flows ('interactive' browser login vs 'service_principal'), the tenant/client credentials the latter requires, the impersonation mechanism for RLS testing, and a hard row ceiling of 10000 with an explicit rationale (preventing bulk extraction into model context). It never explicitly states the operation is read-only/non-mutating or what workspace permissions are needed, which is the remaining gap.

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

Conciseness4/5

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

Front-loaded with a one-line purpose, then the when-to-use list, then a param block — logical and scannable. The closing 'Returns' sentence partly restates a shape already conveyed by the output schema, and the Args block is long, though that length is justified given 0% schema coverage.

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?

For a 9-parameter, auth-sensitive tool with no annotations, this covers purpose, selection criteria, every parameter, credential requirements, and safety limits on row volume. Missing elements are secondary: error/failure behavior, workspace permission prerequisites, and guidance relative to the DAX-related siblings; return values are already covered by the output schema.

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%, so the description must compensate entirely — and it does, documenting all nine parameters including the easily-missed testing-only fabric_client. It adds meaning the schema lacks: the two valid values for auth_mode (which has no enum in the schema), the dependency of tenant_id on service_principal mode, the default and 10000 ceiling for max_rows, and concrete DAX syntax examples for dax_query.

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

Purpose4/5

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

States a specific verb and resource: 'Execute a DAX query against a published Power BI semantic model / Fabric dataset.' That is unambiguous and far beyond the bare tool name. It does not, however, distinguish itself from the sibling run_dax_regression, which an agent could plausibly confuse with 'run or test a 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 supplies an explicit 'Use this tool when the user asks to:' list covering data inspection, measure/KPI verification, and RLS testing via impersonation — clear positive selection criteria. It stops short of stating when NOT to use it or naming which sibling to use instead (e.g. run_dax_regression for suites).

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