Powerbi MCP

Power BI MCP Safety and Execution Protocol

The agent proposes, the user approves, and then the agent executes. Apply this protocol to every Power BI MCP session.

Architecture Boundary

• Report layer: visuals, charts, colors, tooltips, and formatting. Provide manual specifications only.
• Power Query / M layer: data sources and transformations. Draft M code for manual application; do not apply it through semantic-model tools.
• Semantic model layer: DAX measures, tables, relationships, roles, and TMDL. This is the MCP read/write scope.

Action Tiers

Tier 1: Read-only

No confirmation is required, but announce the read scope. Examples: schema and metadata reads, dependency analysis, row counts, data-quality queries, TMDL export, and drafting unapplied DAX or M.

Tier 2: Structural write

Confirm before creating or modifying measures, calculated objects, relationships, folders, format strings, or RLS roles and rules.

Use this template:

Proposed Power BI change (Tier 2)
Target: <workspace/model and object names>
Changes: <itemized changes>
Validation: <checks to run afterward>
Rollback: <backup/TMDL restore approach>

Reply YES to apply exactly these changes. Any scope change requires a new proposal.

Tier 3: Destructive or broad write

Require a confirmed save/export checkpoint, itemize every object, and confirm before execution. Tier 3 includes deletion, irreversible structural changes, and batches affecting two or more objects.

Use this template:

Destructive Power BI change (Tier 3)
Checkpoint: <confirmed save or TMDL backup and timestamp>
Targets: <every affected object>
Impact: <dependencies and expected behavior change>
Rollback: <exact restore procedure>
Validation: <checks to run afterward>

Reply CONFIRMED to apply only the itemized changes.

Ambient Statement Intercept

Do not execute statements such as "I'm going to...", "we should probably...", "I think I'll...", "we no longer need...", or "at some point...". Treat them as planning context.

Execute only an unambiguous imperative or confirmation such as "apply this", "go ahead", YES, or CONFIRMED, and only within the approved scope.

Session Startup Checklist

Complete before any Tier 2 or Tier 3 action:

• Identify the target workspace, semantic model, and connection.
• Confirm the most recent manual save timestamp.
• Confirm a TMDL export or other recoverable backup.
• Agree on session scope: read-only, DAX authoring, structural, or destructive.
• Read the relevant objects and dependencies.
• Check model size and split large work into logical batches.

For 50-150 measures, export TMDL before writes. For 150-300, split work by domain. Above 300, require TMDL export and a dependency map before writes.

Power Query / M Delivery

M code is advisory and must not be applied through semantic-model MCP tools. Wrap it as follows:

Power Query / M code - manual application required
Location: <query or transformation step>
Purpose: <intended effect>

<M code>

Review credentials, privacy levels, query folding, and refresh behavior in Power Query before applying. This code has not been executed.

Never include plaintext credentials or tokens.

DAX Standards

• Prefer measures over calculated columns when the calculation can remain query-time.
• Use DIVIDE(numerator, denominator, alternateResult) instead of bare division.
• Qualify column references as 'Table'[Column]; leave measure references unqualified as [Measure].
• Make filter context explicit with CALCULATE, direct predicates, KEEPFILTERS, ALL, or ALLEXCEPT as appropriate.
• Use ISINSCOPE for hierarchy-aware matrix behavior.
• Use a marked date table and explicit scope for time intelligence.
• Avoid duplicate measures, redundant measure aliases, table-wide FILTER when a column predicate works, and production EVALUATEANDLOG.
• Add a business description, format string, and dependency notes for every visible measure.
• Use format strings consistently: currency such as $#,0.00, percentages such as 0.00%, and integers such as #,0.
• Organize measures into stable business-domain display folders; use a dedicated Key Metrics folder only for genuinely cross-domain KPIs.

Validate syntax, dependencies, format, blank/divide-by-zero behavior, filter context, and representative totals before declaring a measure complete.