powerbi-orchestrator-mcp

Overview Schema Source Related Servers Discussions Admin

abstract_measures

Detect duplicated DAX logic across measures in a Power BI semantic model and identify measures that compute the same thing and could share a calculation group or helper table.

Instructions

Find the logic that is written more than once in a semantic model.

Use this tool when the user asks to:

Find duplicated or copy-pasted logic across measures.
Know which measures compute the same thing and could share one.
Find the measures that differ only in a number or a column, which is what a calculation group is for.

Args: pbip_path: Path to the root .pbip directory. table: Only look at the measures of this table. min_group_size: How many measures have to share a shape before it is reported. Two is the minimum.

Returns: Dict with the groups found and, for each, what the duplication looks like: which measures share it and where exactly they differ.

It does not write anything and does not apply the abstraction. A
Tabular measure cannot take a parameter, so the answer is a
calculation group, a helper table or a rewrite in place — and
which one is right depends on the model.

Input Schema

Name	Required	Description	Default
`table`	No
`pbip_path`	Yes
`min_group_size`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.23.0Oct 23, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does reasonably well: it explicitly states 'It does not write anything and does not apply the abstraction', and warns that the fix is context-dependent (calculation group vs helper table vs rewrite). It omits cost/performance characteristics on large models and any permission requirements for reading a .pbip directory.

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 the core purpose, then a scannable bulleted usage block, then Args/Returns. The closing paragraph on why the answer must be a calculation group/helper table/rewrite is slightly discursive but earns its place by managing expectations about output.

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?

Even though an output schema exists (so return values needn't be spelled out), the description still summarizes the returned grouping structure usefully. Combined with coverage of all three args and the read-only caveat, an agent has what it needs; the only shortfall is no guidance on model size limits or failure modes.

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate and largely does: pbip_path is defined as the root .pbip directory, table as a scoping filter, and min_group_size as the sharing threshold with 'two is the minimum' clarifying the floor. Minor gap: pbip_path doesn't clarify whether relative or absolute paths are accepted.

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?

Specific verb (find duplicated logic) plus a precisely scoped resource (measures in a semantic model), with concrete examples of what 'duplication' means (copy-pasted, same computation, differ only by a number/column). It doesn't explicitly name the neighboring tools it should be distinguished from (e.g. refactor_to_calculation_groups, simplify_dax_measure), so sibling separation is inferential rather than stated.

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?

A bulleted 'use this tool when the user asks to' block gives three concrete triggering intents, which is well above implied usage. It also implicitly separates itself from the applier by stating 'does not apply the abstraction', but never names the alternative tool or states when NOT to use this one.

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