powerbi-orchestrator-mcp

Overview Schema Source Related Servers Discussions Admin

add_measure_with_validation

Add a DAX measure to a Power BI model with automated linting and validation. Dry-run by default to catch syntax and best-practice issues before writing to disk.

Instructions

Add a DAX measure to a semantic model with automated linting and validation.

Use this tool when the user asks to:

Create or add a new DAX measure to a Power BI model.
Validate DAX syntax and best practices (preventing division by zero, unformatted measures, etc.).
Dry-run a measure to check for lint issues before committing to TMDL.

Args: target: Target PBIP directory or TMDL path. measure_name: Name of the measure to create. table: Target table where the measure will reside. expression: DAX formula for the measure (e.g. "DIVIDE([Total Sales], [Units], 0)"). format_string: Format string (e.g. "$#,##0.00", "0.0%"). description: Measure documentation or business description. is_hidden: Whether the measure should be hidden in report view. fail_on_severity: Minimum lint severity that blocks creation ("error", "warning", "info"). dry_run: If True (DEFAULT), validate lint rules without writing to disk. Pass dry_run=False explicitly to persist the measure. runtime_check: Whether to execute the measure against an active engine if connected. measure_writer: Optional custom measure writer callable. Not reachable from an MCP client — the server wires the modeling engine instead.

Returns: Dict with success status, lint findings, and modified file paths.

Input Schema

Name	Required	Default
`table`	Yes
`target`	Yes
`dry_run`	No
`is_hidden`	No
`expression`	Yes
`description`	No
`measure_name`	Yes
`format_string`	No
`runtime_check`	No
`measure_writer`	No
`fail_on_severity`	No	warning

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.18.0Oct 17, 2026
- changedInput schema / properties / dry_run / default
```
Previous value: -falseNew value: +true
```
First observedv0.1.0Sep 10, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and mostly succeeds: it discloses that dry_run defaults to True and only dry_run=False persists, that fail_on_severity gates creation, that runtime_check needs an active engine, that lint findings are returned, and that measure_writer is not reachable from an MCP client. It does not state required permissions or whether an existing measure is overwritten.

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 purpose, then usage, then args, then returns – a clean hierarchy. The Args block is long but earns its place given 0% schema coverage; the only mild redundancy is restating parameter names alongside the schema.

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?

Given 11 parameters, a default-on dry-run safety gate, and a mutation target, the description covers usage, all arguments, and the return payload (success status, lint findings, modified file paths). It omits error/failure modes and permission prerequisites, which are the only remaining gaps for a write 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%, yet the description documents every meaningful parameter with type-appropriate examples ('$#,##0.00', 'DIVIDE([Total Sales], [Units], 0)') and clarifies the enum values for fail_on_severity. It fully compensates for the schema gap, including flagging the one parameter an agent cannot use.

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?

States a specific verb and resource ('Add a DAX measure to a semantic model') plus the differentiator ('with automated linting and validation'). No sibling tool in the list adds measures, so the resource boundary is unambiguous.

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?

Explicit 'Use this tool when the user asks to:' section gives three concrete trigger conditions, including dry-running before committing. It stops short of naming when NOT to use it or which sibling to prefer (e.g. execute_dax_query for querying, run_dax_regression for testing), so it is clear context without exclusions.

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