Skip to main content
Glama

powerbi-orchestrator-mcp

Un servidor MCP orquestrador que unifica modelado semántico, autoría de reportes, nube Fabric, validación y visualización/UX para Power BI / Fabric en 31 herramientas de alto nivel (no 500 primitivas).

El orquestrador delega a motores especializados (subprocess) y presenta al LLM una superficie coherente y de alto nivel.

Tests Coverage Python License MCP

Status: v1.23.1 — Beta. 31 tools, 89% cobertura, enterprise hardening (per-tool scopes, read- and write-path containment, plan ownership, full audit trail). Every state-changing tool is safe by default: dry_run=True on deploy_to_workspace and run_refresh, per-step confirmation on apply_plan, and Tools.Write required for mutating tools over HTTP. Every tool also reports what it actually did: a check that could not run says so instead of returning a green result, a rollback that only partly succeeded is reported as partial, and a step says which engine served it. See release notes · changelog.


Quickstart (60 segundos)

# 1. Install from PyPI.
pip install powerbi-orchestrator-mcp

# 2. Configure your MCP client (Claude Desktop shown).
#    Edit claude_desktop_config.json:
{
  "mcpServers": {
    "powerbi-orchestrator-mcp": {
      "command": "powerbi-orchestrator-mcp",
      "args": ["--start"],
      "env": {"PBI_AUTH_MODE": "interactive"}
    }
}
# 3. Verify the orchestrator itself works.
powerbi-orchestrator-mcp --start  # runs over stdio
# Or in another terminal, run the smoke test:
python scripts/verify_mcp_server.py

That's it — your LLM now sees 31 tools for Power BI / Fabric. See the examples/ directory for 3 reproducible workflows.

Antes de usarlo con datos de clientes, la suite de tests no cubre nada contra una API real. Sigue docs/pilot-validation.md y ejecuta el preflight de solo lectura:

python scripts/pilot_check.py --workspace-id <ws-id> --dataset-id <ds-id>

Related MCP server: Microsoft Fabric RTI MCP Server

Defaults de seguridad (léelo antes de tocar producción)

Todas las tools que modifican estado son safe-by-default. Nada escribe en un workspace real ni en disco sin una acción explícita.

Tool

Default

Cómo se ejecuta de verdad

deploy_to_workspace

dry_run=True

dry_run=False

run_refresh

dry_run=True

dry_run=False

apply_plan

dry_run=True

dry_run=False (+ confirm_each_step)

promote_in_pipeline

dry_run=True

dry_run=False

run_dax_regression

no ejecuta sin dataset

pasar workspace_id + dataset_id

Además:

  • Sin secretos en el contexto del LLM. Ninguna tool acepta un client_secret. Las credenciales se leen del entorno (PBI_CLIENT_ID / PBI_TENANT_ID / PBI_CLIENT_SECRET, o los equivalentes AZURE_*) o de una workload identity.

  • Las escrituras están contenidas. Las tools que escriben en disco rechazan rutas fuera de PBI_WORKSPACE_ROOT, que por defecto es el directorio de trabajo del proceso.

  • Las lecturas también. Leer es cómo el contenido llega al contexto del modelo, así que el path de lectura sigue la misma regla que el de escritura. La precedencia es deliberada: un PBI_WORKSPACE_ROOT configurado es la frontera y nada lo ensancha; PBI_ALLOW_OUTSIDE_WORKSPACE_READ=1 la quita solo cuando no hay ninguna configurada (en ese caso la frontera es el directorio de trabajo del proceso). Los directorios del sistema y de credenciales (/etc, /run, ~/.ssh, ~/.config…) se rechazan siempre.

  • Auditoría de todo lo que muta. Las 20 tools con efecto sobre el workspace dejan registro (success / failed / dry_run / partial / rolled_back) en un log encadenado con HMAC. Los valores guardados bajo una clave que nombra un secreto se redactan enteros.

  • La auditoría dice quién. Cada entrada lleva el actor en una columna propia: el principal ligado sobre HTTP, el usuario del sistema operativo que corre el proceso sobre stdio (marcado local:). La columna está dentro de la cadena, así que el actor no se puede retocar después sin romperla. No se redacta a propósito: un principal suele ser una UPN, y el redactor convierte los emails en hashes — que no es una atribución.

  • Un servidor en solo-lectura. PBI_READONLY=1 (o --readonly en la línea de comandos) rechaza toda tool que modifique estado, sea quien sea el que llame: es una propiedad del despliegue, no del llamador. Un principal con Tools.Admin tampoco puede saltárselo.

  • El despliegue se reporta a sí mismo. Al arrancar, y en powerbi_health, el servidor dice si la frontera de lectura está activa, dónde está el root del workspace, si el transporte hace que los scopes signifiquen algo, si el audit log es fail-closed y si el home del orquestador se puede escribir. Un despliegue que apagó la frontera de lectura lo dice.

  • DAX acotado. execute_dax_query devuelve como máximo 1000 filas por defecto (techo 10 000) y marca el truncamiento.

  • Scopes por tool sobre transporte HTTP: cada una de las 31 tools declara el scope que necesita. Las que modifican el workspace o la nube requieren Tools.Write; liberar entre etapas de un pipeline y aplicar sensitivity labels requieren Tools.Admin; Tools.Admin concede todos los inferiores. Las que solo producen ficheros dentro del workspace (el diccionario de datos, las capturas) siguen siendo de lectura, pero su ruta de salida se valida como escritura y queda dentro del workspace. Cada sesión HTTP queda ligada a la credencial que la abrió: otra credencial recibe 404.

  • Los planes tienen dueño. Cada plan registra la identidad que lo creó y solo su dueño puede leerlo, listarlo o borrarlo; conocer el plan_id no alcanza.

  • Plugins desactivados por defecto. Cargar un plugin ejecuta Python arbitrario, así que requiere PBI_ENABLE_PLUGINS=1 y un directorio escribible solo por el propietario.

Lo que una tool te dice es lo que ocurrió

Este proyecto no reporta éxito por trabajo que no hizo:

  • Una validación que no pudo ejecutarse (por ejemplo, BPA sin Tabular Editor) devuelve un score parcial con la lista de checks omitidos, no un 100.

  • Un paso de plan sin ejecutor falla con el nombre de la acción, en vez de devolverse como aplicado.

  • run_dax_regression falla si no encuentra el baseline: sin baseline no hay nada contra qué comparar.

  • apply_plan distingue rolled_back de rollback_partial y de rollback_incomplete, y cada entrada del rollback lleva su estado real.

Detalle completo del modelo de amenazas en SECURITY.md, incluidos los controles que no existen.


Arquitectura de 3 capas (importante)

El proyecto NO es un wrapper sobre los MCP servers existentes. Es un servidor MCP propio que consume otros MCP servers como subprocess. Esto es lo que permite presentar al LLM 31 tools coherentes en lugar de 500 primitivas dispersas.

┌─────────────────────────────────────────────────────────────────┐
│ Capa 1: MCP Client (Claude Desktop, VS Code, Copilot, Cursor)    │
│         Habla JSON-RPC sobre stdio con el orquestrador.          │
│         El LLM ve 31 tools de alto nivel.                        │
└────────────────────────────┬────────────────────────────────────┘
                             │ stdio + JSON-RPC
┌────────────────────────────▼────────────────────────────────────┐
│ Capa 2: powerbi-orchestrator-mcp (ESTE PAQUETE — Python)        │
│         Distribuido via PyPI: pip install powerbi-orchestrator-mcp│
│         Console script: powerbi-orchestrator-mcp                 │
└────────────────────────────┬────────────────────────────────────┘
                             │ subprocess + JSON-RPC sobre stdio
┌────────────────────────────▼────────────────────────────────────┐
│ Capa 3: Engines individuales (heterogéneos)                       │
│         powerbi-modeling-mcp → npm: npx @microsoft/...          │
│         te (Tabular Editor)    → .NET binary                     │
│         superbi-mcp             → npm: npx superbi-mcp            │
│         python_report           → built-in (parte del orquestrador)│
└─────────────────────────────────────────────────────────────────┘

La capa 3 son los motores a los que el orquestrador despacha, y son todos los que el health check reporta: si aparece ahí, alguna tool lo usa.

Por qué npm NO es necesario para instalar el orquestrador (sí para correr operaciones reales): npm es una dependencia RUNTIME de los engines, no del orquestrador. El paquete powerbi-orchestrator-mcp se publica solo en PyPI.


Qué es

Un servidor Model Context Protocol (stdio) que expone 31 herramientas de alto nivel para que un agente IA pueda trabajar end-to-end con Power BI:

  • Diseñar y validar modelos semánticos (TMDL/TOM).

  • Crear, editar y auditar reportes (.pbix, PBIP/PBIR).

  • Operar en la nube (Fabric / Power BI Service): workspaces, datasets, refresh, deployment pipelines, RLS, Git integration.

  • Auditar calidad (BPA, lint DAX, accesibilidad WCAG, star-schema).

  • Diseñar visualizaciones con razonamiento de UX/storytelling.

Qué problema resuelve

Los MCPs existentes cubren partes:

  • powerbi-modeling-mcp (oficial MS): solo modelo semántico, no toca reportes.

  • superbi-mcp (cyphonica, 490 tools): local, Windows-only, FSL.

  • powerbi-mcp (sulaiman013, 82 tools): cloud paths mock-tested, no live.

  • fabric-rti-mcp, Fabric Core MCP: solo nube, no autoría local.

Nadie entrega orquestación cross-engine + nube maduro + UX verificable. powerbi-orchestrator-mcp sí.

Instalación

1. Instalar el orquestrador (Python)

pip install powerbi-orchestrator-mcp

El paquete está publicado en PyPI: https://pypi.org/project/powerbi-orchestrator-mcp/

Para desarrollo local (con tests y dev dependencies):

git clone https://github.com/berriosb/powerbi-orchestrator-mcp.git
cd powerbi-orchestrator-mcp
pip install -e ".[dev]"

El comando powerbi-orchestrator-mcp queda disponible en el PATH.

2. Instalar engines opcionales (solo si vas a usar operaciones reales)

Los engines son dependencias runtime del orquestrador. Si solo vas a probar con python_report (built-in), no necesitas instalar nada más.

# Node.js + npm (para powerbi-modeling-mcp, superbi-mcp)
# macOS:   brew install node
# Linux:   apt install nodejs npm
# Windows: https://nodejs.org/

# Tabular Editor CLI (BPA)
# Windows/macOS: https://github.com/TabularEditor/TabularEditor/releases
# Linux: dotnet tool install --global TabularEditor

Los engines que el orquestrador despacha son esos tres, y son los únicos que el health check reporta: si aparece ahí, alguna tool lo usa. La validación PBIP que el orquestrador ejecuta es su propio validador estructural, que no necesita binario externo.

Ver docs/engines-setup.md para detalles de instalación por engine y troubleshooting.

3. Configurar el MCP client

Edita la config de tu MCP client (ej. claude_desktop_config.json):

{
  "mcpServers": {
    "powerbi-orchestrator-mcp": {
      "command": "powerbi-orchestrator-mcp",
      "args": ["--start"],
      "env": {
        "PBI_AUTH_MODE": "interactive",
        "PBI_WORKSPACE_ROOT": "/ruta/a/tus/pbip"
      }
    }
  }
}

PBI_WORKSPACE_ROOT acota las lecturas y las escrituras del orquestador a ese directorio. Si no lo pones, se usa el directorio de trabajo del proceso. Apunta ahí donde tengas tus .pbip: es la raíz del workspace desde el punto de vista del agente.

Compatible con VS Code + Copilot, Claude Desktop, OpenClaw, Hermes, Claude Code, Cursor y cualquier cliente MCP stdio.

4. Probar

En tu cliente MCP, el LLM ve 31 tools de alto nivel, agrupadas por capa:

Sesión y planificación

  • connect_target — abrir sesión contra un PBIP / Fabric workspace / PBI Desktop

  • plan_change — crear un plan versionable

  • apply_plan — ejecutar el plan con rollback

Modelado semántico

  • create_semantic_model_from_schema, add_measure_with_validation, refactor_to_calculation_groups, diff_models, generate_data_dictionary

Refactoring del modelo

  • simplify_dax_measure — reescribir una medida DAX en su forma corta equivalente

  • abstract_measures — la lógica que está escrita más de una vez

  • abbreviate_names — nombres de medidas y columnas que se han hecho demasiado largos

Autoría de reportes

  • create_report_from_dataset, edit_report_visual, design_report_page_from_requirements, select_visuals_for_kpis, screenshot_report_pages, optimize_report_performance

Nube Fabric / Power BI Service

  • deploy_to_workspace, run_refresh, promote_in_pipeline, setup_rls_and_roles, set_sensitivity_labels, commit_workspace_to_git, sync_git_to_workspace, pre_deploy_check, execute_dax_query

Auditoría y calidad

  • audit_model_and_report, audit_report_ux_and_storytelling, apply_theme_and_accessibility_rules, run_dax_regression

Diagnóstico

  • powerbi_health

Con connect_target + plan_change + apply_plan solos, el LLM ya puede hacer safe_rename, audit, deploy y regression sobre cualquier PBIP local (sin engines externos) o cualquier Fabric workspace (con powerbi-modeling-mcp instalado).

Tres flujos completos, de principio a fin

Los tres están en examples/, con los JSON de respuesta esperados. Aquí va el esqueleto de cada uno.

1. Renombrar una columna sin romper nada

El flujo más importante para un analista: cambiar el nombre de una columna y que las referencias del modelo y del reporte se muevan juntas.

connect_target(
    target_type="pbip_folder",
    target_ref="/ruta/a/tus/sales.pbip"
)

plan_change(
    intent="safe_rename",
    options={
        "old_path": "FactSales[UnitPrice]",
        "new_path": "FactSales[Price]",
        "scope": "full"
    }
)

apply_plan(
    plan_id="<el que devolvió plan_change>",
    dry_run=false,
    confirm_each_step=false
)

plan_change devuelve un plan versionable (YAML) que puedes commitear a Git antes de aplicarlo. apply_plan ejecuta los pasos con rollback entre motores, y devuelve partial si el rollback no lo revirtió todo. Después del rename, el paso de reporte dice cuántas referencias reescribió — un rename que no encuentra nada en un PBIR real es un dato, no un éxito.

→ examples/01-safe-rename/

2. Publicar en Fabric con el gate delante

El gate evalúa findings, no ficheros: primero auditas, y le pasas el resultado a pre_deploy_check y a deploy_to_workspace.

audit_model_and_report(
    pbip_path="/ruta/a/tus/sales.pbip"
)

pre_deploy_check(
    findings_json="<los findings de la auditoría>",
    profile="strict"
)

deploy_to_workspace(
    pbip_path="/ruta/a/tus/sales.pbip",
    workspace_id="<workspace>",
    findings_json="<los mismos findings>",
    gate_profile="strict",
    dry_run=true          # ← empieza siempre por aquí
)

run_refresh(
    workspace_id="<workspace>",
    dataset_id="<dataset>",
    dry_run=true
)

pre_deploy_check falla cerrado: sin findings no pasa, y una severidad que el perfil no conoce bloquea. Un despliegue bloqueado igual lista las operaciones que habría hecho, para que el dry run siga siendo informativo. dry_run viene en true por defecto en las dos tools que escriben en la nube, así que hay que desactivarlo a propósito.

→ examples/02-deploy-pbip/

3. Auditar, arreglar, volver a auditar

audit_model_and_report(
    pbip_path="/ruta/a/tus/sales.pbip"
)

apply_theme_and_accessibility_rules(
    pbip_path="/ruta/a/tus/sales.pbip",
    palette="okabe_ito",
    auto_backfill_alt_text=true
)

add_measure_with_validation(
    target="/ruta/a/tus/sales.pbip",
    table="FactSales",
    measure_name="Revenue",
    expression="SUM(FactSales[Price])"
)

audit_model_and_report(
    pbip_path="/ruta/a/tus/sales.pbip"
)   # segunda pasada

El bucle es el punto: auditar, corregir, auditar otra vez. La segunda pasada es la que dice si el arreglo funcionó.

→ examples/03-audit-then-fix/

Estado actual (v1.23.1)

  • ✅ 31 tools implementadas (modelado, refactoring, reportes, nube, auditoría, UX, DAX)

  • ✅ Cross-engine rollback

  • ✅ Audit log encadenado con HMAC, con anchor firmado

  • ✅ PlanBuilder con templates versionables

  • ✅ Motores registrados: python_report y python_modeling (built-in), powerbi-modeling-mcp, superbi-mcp, te (Tabular Editor, para BPA). Cada paso dice qué motor lo sirvió

  • ✅ Scopes por tool (las 31 declaran el suyo) y Tools.Admin para las operaciones de gobernanza

  • ✅ Lecturas y escrituras acotadas al workspace (PBI_WORKSPACE_ROOT)

  • ✅ Planes con dueño: conocer el plan_id no alcanza para leerlos ni borrarlos

  • ✅ Story variance analysis (detección de regresiones visuales)

  • ✅ mypy --strict clean, ruff clean, CI matrix Linux/macOS/Windows

  • ✅ Publicado en PyPI: https://pypi.org/project/powerbi-orchestrator-mcp/

Pendiente, y es deliberado:

  • ⏳ Los E2E contra un tenant real siguen siendo manuales (pilot-validation.yml, workflow_dispatch). Los secrets no existen todavía en el repo, así que automatizarlo sin tenant es teatro.

  • ⏳ La propiedad de planes vive en un SQLite local, no en un IdP.

  • ⏳ El audit log es fail-open por defecto: una escritura fallida no detiene la mutación, se reporta como aviso en el resultado. Con PBI_AUDIT_FAIL_CLOSED=1 deja de serlo.

Ver docs/releases/RELEASE-NOTES-v1.23.1.md para el detalle de la última release y CHANGELOG.md para el historial completo.

Licencia

MIT.

Atribución

Available Tools

31 tools
abbreviate_namesA

Propose shorter names for the measures and columns that need them.

Use this tool when the user asks to:

  • Shorten, abbreviate or tidy up measure and column names.

  • Find the names that have grown too long to read.

  • Prepare a batch of renames before applying them.

Args: pbip_path: Path to the root .pbip directory. kind: "measures", "columns" or "both". max_length: Above this length, a name is a candidate. abbreviate_words: Shorten the words that have a standard abbreviation ("Amount" to "Amt", "Quantity" to "Qty"). drop_filler_words: Drop the words that carry no meaning ("of", "the", "in").

Returns: Dict with the proposals and a rename map ready for plan_change(intent="safe_rename").

It does not rename anything. A name that cannot be shortened
without changing what it says is reported as needing a name by
hand, and a proposal that would collide with an existing name
is adjusted.

Inputs: pbip_path (required), kind, max_length, abbreviate_words, +1 more. Returns: object

abstract_measuresA

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.

Inputs: pbip_path (required), table, min_group_size. Returns: object

add_measure_with_validationA

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.

Inputs: table (required), target (required), expression (required), measure_name (required), +7 more. Returns: object

apply_planA

Execute an approved plan with automatic rollback on step failure.

Use this tool when the user asks to:

  • Execute or apply an approved plan created by plan_change.

  • Run plan steps in dry-run mode before modifying actual files.

  • Approve each step individually before it runs.

Args: plan_id: ID of the plan previously created by plan_change. dry_run: If True (DEFAULT), simulate execution without modifying files or cloud resources. Pass dry_run=False explicitly to apply for real. confirm_each_step: If True, ask the user to approve every step before it runs. Declining (or having no interactive client) stops execution and reports the remaining steps as not run.

Returns: ApplyResult with execution status, executed steps, and rollback details if needed.

Inputs: plan_id (required), dry_run, confirm_each_step. Returns: Output schema for apply_plan (spec section 3.3).

apply_theme_and_accessibility_rulesA

Apply a colorblind-safe theme, backfill visual alt text, and re-audit WCAG.

Use this tool when the user asks to:

  • Make a report accessible and WCAG 2.1 compliant.

  • Apply a colorblind-safe palette (e.g. Okabe-Ito, ColorBrewer).

  • Automatically generate informative alt text for visuals lacking descriptions.

Args: pbip_path: Path to the .pbip directory. palette: Colorblind-safe palette name ("okabe_ito", "colorbrewer"). auto_backfill_alt_text: Whether to generate missing alt text on visuals. alt_text_template: Format template for generated alt text.

Returns: Dict with updated WCAG score, modified visual count, and theme update details.

Inputs: pbip_path (required), palette, alt_text_template, auto_backfill_alt_text. Returns: object

audit_model_and_reportA

Composite quality and compliance audit on a Power BI project (PBIP).

Use this tool when the user asks to:

  • Audit, inspect, or validate a Power BI project (.pbip) or semantic model.

  • Check Best Practice Analyzer (BPA) rules, DAX code quality, or naming conventions.

  • Validate WCAG 2.1 accessibility (contrast, missing alt text, chart readability).

Args: pbip_path: Path to the root .pbip directory or folder. bpa_ruleset: Best practice ruleset to run ("default", "strict", "lenient"). dax_measures_json: Optional JSON string or dictionary mapping measure names to DAX expressions. bpa: Whether to execute Tabular BPA checks. dax_lint: Whether to execute static DAX linting checks. accessibility: Whether to audit WCAG 2.1 accessibility on report pages. naming: Whether to validate column, measure, and table naming conventions.

Returns: Dict with overall score (0-100), pass/fail status, and categorized findings.

Inputs: pbip_path (required), bpa, naming, dax_lint, +3 more. Returns: object

audit_report_ux_and_storytellingA

Evaluate report storytelling, visual hierarchy, cognitive load, and UX design.

Use this tool when the user asks to:

  • Audit report design quality, narrative flow, or visual hierarchy.

  • Check if a report follows dashboard best practices for a specific audience.

Args: pbip_path: Path to the .pbip directory. page_name: Optional specific page name to audit; audits all pages if omitted. audience_assumed: Target audience ("executive", "analytical", "operational"). strictness: Scoring strictness ("lenient", "standard", "strict").

Returns: Dict with UX score (0-100), category breakdowns (hierarchy, density, narrative), and suggestions.

Inputs: pbip_path (required), page_name, strictness, audience_assumed. Returns: object

commit_workspace_to_gitA

Export and commit a Fabric workspace into a local Git repository.

Use this tool when the user asks to:

  • Back up or version-control a Fabric workspace into Git.

  • Snapshot reports and semantic models into local PBIP files with Git commits.

Args: workspace_id: Source Fabric workspace ID (UUID). output_repo_path: Local path to destination Git repository. branch: Git branch to commit into. commit_message: Commit message describing the snapshot. exclude_items: Optional list of item IDs to exclude. dry_run: If True, inspect items without creating git commits.

Returns: Dict with committed items, commit SHA, and repository status.

Inputs: workspace_id (required), output_repo_path (required), branch, dry_run, +2 more. Returns: object

connect_targetA

Connect to a Power BI target and initialize an orchestrator session.

Use this tool when the user asks to:

  • Connect to a Power BI Desktop session, Fabric workspace, PBIP folder, or PBIX file.

  • Start an interactive session to inspect or modify Power BI assets.

Args: target_type: One of "pbi_desktop", "fabric_workspace", "pbip_folder", "pbix_file". target_ref: Reference path (for PBIP/PBIX) or workspace UUID (for Fabric). auth_mode: "interactive" (browser login) or "service_principal". When omitted, PBI_AUTH_MODE is used, falling back to "interactive". tenant_id: Azure AD tenant ID (required when auth_mode is service_principal).

Returns: ConnectResult with session_id, engines_available status, and any diagnostic warnings.

Inputs: target_ref (required), target_type (required), auth_mode, tenant_id. Returns: Output schema for connect_target (spec section 3.1).

create_report_from_datasetA

Scaffold a PBIR report folder and layout from an existing semantic model.

Use this tool when the user asks to:

  • Create a new report (.Report folder) for an existing dataset.

  • Generate starter report pages with cards, charts, and an accessible theme.

Args: pbip_path: Path to the .pbip directory containing the dataset. page_name: Name of the initial report page (default: "Overview"). visual_count: Number of starter visuals to generate. theme: Theme name to apply (default: "okabe_ito"). include_card: Whether to generate a top-line KPI card visual. inspector: Optional model inspector.

Returns: Dict with created page path, visual IDs, and scaffolded report files.

Inputs: pbip_path (required), theme, inspector, page_name, +2 more. Returns: object

create_semantic_model_from_schemaA

Generate a TMDL semantic model and PBIP project from a declarative schema spec.

Use this tool when the user asks to:

  • Create, scaffold, or generate a new Power BI semantic model from scratch.

  • Define tables, columns, data types, relationships, and hierarchies declaratively.

Args: spec_yaml: YAML specification of tables, columns, types, and relationships. spec_json: JSON specification (either as a string or a structured object/dict). output_pbip_path: Target directory to write the generated .pbip project. dry_run: If True, validate specification without writing files to disk.

Returns: Dict with tables created, relationships created, hierarchies created, and validation status.

Inputs: dry_run, spec_json, spec_yaml, output_pbip_path. Returns: object

deploy_to_workspaceA

Deploy a PBIP project to a Fabric/Power BI workspace with pre-deploy gates.

Use this tool when the user asks to:

  • Deploy, publish, or release a Power BI project (.pbip) to Microsoft Fabric or Power BI Service.

  • Run pre-deployment quality gates before publishing.

  • Schedule automatic daily dataset refreshes upon publication.

Args: pbip_path: Local filesystem path to the root .pbip directory. workspace_id: Target Fabric / Power BI workspace ID (UUID). refresh_daily_hour: Daily UTC hour (0-23) for scheduled refresh (default: 6 AM UTC). findings_json: Optional list or JSON string of pre-existing audit findings to evaluate. gate_profile: Quality gate profile ("strict", "standard", "lenient"). auth_mode: "interactive" (browser login) or "service_principal". When omitted, PBI_AUTH_MODE is used, falling back to "interactive". tenant_id: Azure AD tenant ID. client_id: Azure AD client ID. dry_run: When True (default) evaluates the gate and reports the planned operations WITHOUT calling any Fabric API. Pass dry_run=False to actually publish. mock: If True, simulate deployment without calling external APIs.

Returns: Dict with deployment status, gate evaluation results, published item IDs, and refresh configuration.

Inputs: pbip_path (required), workspace_id (required), mock, dry_run, +6 more. Returns: object

design_report_page_from_requirementsA

Synthesize a complete PBIR report page layout from a natural language brief.

Use this tool when the user asks to:

  • Design or generate a new Power BI report page based on business requirements.

  • Automatically select, size, position, and format visuals matching an analytical goal.

  • Apply professional color schemes and visual hierarchy to a page.

Args: pbip_path: Path to the target .pbip directory. brief: Natural language description of what the report page should convey. page_name: Display name for the newly created report page (default: "Overview"). audience: Target audience ("executive", "analytical", "operational"). palette: Color palette name (default: "okabe_ito"). inspector: Optional model inspector for schema context.

Returns: Dict containing synthesized visual containers, positions, and page metadata.

Inputs: brief (required), pbip_path (required), palette, audience, +2 more. Returns: object

diff_modelsA

Compare two semantic models and report structural differences.

Use this tool when the user asks to:

  • Compare two versions of a Power BI model or PBIP directory.

  • See what tables, columns, measures, or relationships changed between branches or releases.

Args: before: Path to the baseline PBIP directory. after: Path to the target PBIP directory.

Returns: Dict detailing added, removed, and modified tables, columns, measures, and relationships.

Inputs: after (required), before (required). Returns: object

edit_report_visualA

Modify a visualContainer in a PBIR report page (type, fields, formatting, layout).

Use this tool when the user asks to:

  • Edit, reformat, or resize a specific chart/visual on a report page.

  • Change visual fields, bindings, alt text, or visibility.

Args: pbip_path: Path to the root .pbip directory. page_name: Name of the page containing the visual. visual_id: Unique ID of the visualContainer to edit. type: New visual type if changing (e.g. "barChart", "lineChart", "card"). fields_json: Optional dict or JSON string specifying field bindings to update. format_json: Optional dict or JSON string specifying formatting options. position_json: Optional dict or JSON string with x, y, width, height layout. alt_text: New alt text for accessibility. is_hidden: Whether to hide the visualContainer.

Returns: Dict with success status, changes applied, and page path.

Inputs: page_name (required), pbip_path (required), visual_id (required), type, +5 more. Returns: object

execute_dax_queryA

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.

Inputs: dax_query (required), dataset_id (required), workspace_id (required), max_rows, +5 more. Returns: object

generate_data_dictionaryA

Generate Markdown documentation and Mermaid ER diagram for a semantic model.

Use this tool when the user asks to:

  • Document a Power BI dataset or semantic model.

  • Generate a data dictionary listing all tables, columns, types, and descriptions.

  • Create a Mermaid entity-relationship (ER) diagram of the model.

Args: pbip_path: Path to the .pbip directory. output_path: Optional file path to save the generated Markdown. inspector: Optional model inspector.

Returns: Dict with data dictionary markdown content, table count, measure count, and output path.

Inputs: pbip_path (required), inspector, output_path. Returns: object

optimize_report_performanceA

Analyze PBIR report pages for visual performance bottlenecks and anti-patterns.

Use this tool when the user asks to:

  • Diagnose slow-loading report pages or improve visual performance.

  • Identify excessive visual density, expensive custom visuals, or unoptimized filters.

Args: pbip_path: Path to the .pbip directory. target_load_ms: Desired maximum page load latency in milliseconds (default: 5000 ms).

Returns: Dict with performance score (0-100), estimated load time, and actionable recommendations.

Inputs: pbip_path (required), target_load_ms. Returns: object

plan_changeA

Create a versionable, multi-step execution plan from an intent template.

Use this tool when the user asks to:

  • Plan a complex or risky operation requiring atomic execution or rollback capability.

  • Safely rename a table or column across both model and visual bindings (intent="safe_rename").

  • Plan an audit, deployment, or DAX regression run.

Args: intent: One of the supported templates ("safe_rename", "audit", "deploy", "dax_regression"). options: Template-specific arguments (e.g. for safe_rename: old_path, new_path, scope). May also contain PlanOptions fields (auto_rollback, max_impact_threshold, dry_run_first).

Returns: PlanResult with plan_id, plan_yaml, steps, risk_score, estimated_changes.

Inputs: intent (required), options. Returns: Output schema for plan_change (spec section 3.2).

powerbi_healthA

Diagnose orchestrator health, detected modeling engines, and storage readiness.

Use this tool when the user asks to:

  • Check if the Power BI MCP orchestrator is running properly.

  • See which external tools/engines are installed (Tabular Editor, DAX optimizer, etc.).

  • Get installation or setup instructions for missing components.

Args: include_engine_details: Whether to return full diagnostic info and remediation tips for each engine.

Returns: Dict with system status, engine availability matrix, active store counts, and remediation advice.

Inputs: include_engine_details. Returns: object

pre_deploy_checkA

Evaluate audit findings against a pre-deployment quality gate profile.

Use this tool when the user asks to:

  • Check whether audit findings block deployment or meet quality criteria.

  • Validate findings against 'strict', 'standard', or 'lenient' governance gates.

Args: findings_json: List or JSON string of audit findings to evaluate. profile: Gate profile to evaluate against ("strict", "standard", "lenient").

Returns: Dict with gate decision (passed=True/False), blocking findings, and warnings.

Inputs: profile, findings_json. Returns: object

promote_in_pipelineA

Promote artifacts across Microsoft Fabric Deployment Pipeline stages.

Use this tool when the user asks to:

  • Promote or move items between Fabric deployment stages (e.g. dev to test, test to prod).

  • Run pre-promotion quality gates before moving items.

Args: pipeline_id: Fabric deployment pipeline ID (UUID). source_stage: Source stage ("dev", "test", "prod"). target_stage: Target stage ("test", "prod"). items: Optional list of specific item IDs to promote. Promotes all if omitted. dry_run: If True (DEFAULT), validate stages and gate checks without triggering actual promotion. Pass dry_run=False explicitly to promote for real — this moves live artifacts between stages.

Returns: Dict with promotion status, gate outcomes, and affected items.

Inputs: pipeline_id (required), items, dry_run, source_stage, +1 more. Returns: object

refactor_to_calculation_groupsA

Consolidate repetitive measures (e.g. YTD, QTD, PY) into calculation groups.

Use this tool when the user asks to:

  • Refactor or clean up redundant DAX measures using calculation groups.

  • Reduce model complexity and standardize time intelligence calculations.

Args: target: Target PBIP directory or TMDL path. min_candidates: Minimum measure patterns needed to trigger consolidation. reconcile_strategy: "strict" or "lenient". preserve_originals: Whether to keep original measures alongside the calculation group. auto_apply: If True, write calculation items immediately; if False, return proposed refactoring plan. inspector: Optional model inspector. measure_writer: Optional measure writer callable.

Returns: Dict with proposed or applied calculation items, candidate measures, and impact assessment.

Inputs: target (required), inspector, auto_apply, measure_writer, +3 more. Returns: object

run_dax_regressionA

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.

Inputs: baseline_path (required), auth_mode, client_id, tenant_id, +5 more. Returns: object

run_refreshA

Trigger, monitor, and optionally wait for a Power BI dataset refresh.

Use this tool when the user asks to:

  • Refresh data in a published Power BI semantic model.

  • Check the completion status of a refresh operation.

  • Perform full, automatic, or data-only refreshes.

Args: workspace_id: Fabric / Power BI workspace ID (UUID). dataset_id: Dataset / semantic model ID (UUID). refresh_type: "full", "automatic", "data_only", "calculate", or "clearValues". wait: Whether to poll and wait for the refresh to complete before returning. timeout_s: Maximum wait time in seconds (default: 1800). auth_mode: "interactive" or "service_principal". When omitted, PBI_AUTH_MODE is used, falling back to "interactive". tenant_id: Azure AD tenant ID. client_id: Azure AD client ID. dry_run: When True (default) no refresh is triggered and status is "DryRun". Pass dry_run=False to actually refresh.

Returns: Dict with refresh status, duration, error details, and rollback status if applicable.

Inputs: dataset_id (required), workspace_id (required), wait, dry_run, +5 more. Returns: object

screenshot_report_pagesA

Capture screenshots or structural wireframes of Power BI report pages.

Use this tool when the user asks to:

  • Visually inspect or capture report pages for reviews or regression diffs.

  • Generate SVG wireframes or image snapshots of PBIR layouts.

Args: pbip_path: Path to the .pbip directory. pages: Optional list of specific page names to capture. format: Output format ("png", "svg", "pdf"). resolution: Target resolution ("desktop", "mobile", "tablet"). output_dir: Directory where captured images are written. wait_ms: Time in ms to wait for visual rendering.

Returns: Dict with output image paths, warnings, and rendering metadata.

Inputs: pbip_path (required), pages, format, wait_ms, +2 more. Returns: object

select_visuals_for_kpisA

Recommend optimal visual types and chart configurations for given KPIs.

Use this tool when the user asks to:

  • Choose the best charts or visual types for a specific set of KPIs or metrics.

  • Tailor visual recommendations to an audience ('executive', 'analytical', 'operational').

  • Get primary and alternative chart suggestions with rationale based on data types.

Args: kpis_json: List of KPIs or JSON string (each with name, semantic_type, fields, etc.). audience: Target persona ("executive", "analytical", "operational"). max_results: Maximum number of alternative visual recommendations per KPI. inspector: Optional model inspector providing column cardinality and schema info.

Returns: Dict with recommended primary visual, alternatives, and rationale for each KPI.

Inputs: kpis_json (required), audience, inspector, max_results. Returns: object

set_sensitivity_labelsA

Apply Microsoft Purview information protection sensitivity labels to items.

Use this tool when the user asks to:

  • Classify or protect Power BI items (reports, semantic models, dashboards).

  • Set Purview sensitivity labels (Confidential, General, Highly Confidential).

Args: items: List of dicts specifying item IDs and types (e.g. [{"id": "...", "type": "Report"}]). label_id: Microsoft Purview label GUID. label_name: Display name of the sensitivity label. admin_scopes: Optional list of administrative authorization scopes. redact_names: Whether to redact item names in returned logs for security. dry_run: If True, validate permissions without applying labels.

Returns: Dict with updated items, failed items, and compliance status.

Inputs: items (required), label_id (required), label_name (required), dry_run, +2 more. Returns: object

setup_rls_and_rolesA

Configure Row-Level Security (RLS) roles and validation rules in a TMDL model.

Use this tool when the user asks to:

  • Set up, add, or configure RLS roles and DAX table filter expressions.

  • Test and validate security rules against sample queries.

Args: target: Target PBIP directory or TMDL path. spec_yaml: YAML specification of security roles, members, and DAX filters. spec_json: JSON specification (either as a string or a structured object/dict). dry_run: If True, validate role specification without writing to disk. rollback_on_test_failure: Whether to revert modifications if test queries fail.

Returns: Dict with roles created, test query outcomes, and rollback status if applicable.

Inputs: target (required), dry_run, spec_json, spec_yaml, +1 more. Returns: object

simplify_dax_measureA

Rewrite a DAX expression in its shorter, equivalent form.

Use this tool when the user asks to:

  • Simplify, tidy or shorten a DAX measure.

  • Find the measures in a model that are written the long way.

  • Replace a hand-rolled blank check, error check or IF chain with the function that already does it.

Args: expression: The DAX expression to simplify. Mutually exclusive with pbip_path. pbip_path: A PBIP project to read the measures from. measure: The measure to simplify. Requires pbip_path. all_measures: Simplify every measure in the project and report which ones could be written shorter. Requires pbip_path. apply_lint: Include the linter verdict before and after, so a rewrite that silences a finding — or creates one — is visible.

Returns: Dict with the simplified expression and the rewrites that produced it. The equivalence is structural: the expression is never evaluated against data, so the rewrite changes the shape and not the meaning, and a reader can check it. An expression that could not be parsed comes back unchanged, with the reason.

This tool writes nothing. To apply the result, pass the
simplified expression to add_measure_with_validation.

Inputs: measure, pbip_path, apply_lint, expression, +1 more. Returns: object

sync_git_to_workspaceA

Deploy a local Git repository with PBIP projects to a Fabric workspace.

Use this tool when the user asks to:

  • Synchronize or publish a local Git repository or branch to a Fabric workspace.

  • Update workspace items based on version-controlled PBIP files.

Args: repo_path: Path to the local Git repository. workspace_id: Target Fabric workspace ID (UUID). branch_or_commit: Git ref to sync (default: "HEAD"). conflict_resolution: Conflict handling strategy ("manual", etc.). dry_run: If True, calculate changes without publishing.

Returns: Dict with synchronized items, skipped items, and deployment results.

Inputs: repo_path (required), workspace_id (required), dry_run, branch_or_commit, +1 more. Returns: object

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.7/5.0

    Scored across 31 tools

    Disambiguation4/5

    Most tools target clearly distinct operations across modeling, reporting, deployment, security, and governance. A few boundaries are softer, such as create_report_from_dataset versus design_report_page_from_requirements, and audit_report_ux_and_storytelling versus optimize_report_performance, but their descriptions generally disambiguate them.

    Naming Consistency4/5

    The set is consistently snake_case and mostly follows a verb_noun pattern (e.g., execute_dax_query, create_report_from_dataset, set_sensitivity_labels). Minor deviations exist, such as powerbi_health and pre_deploy_check being noun-first, and inconsistent use of to/in connectors (deploy_to_workspace vs promote_in_pipeline).

    Tool Count2/5

    With 31 tools, the surface is heavy for an agent to navigate and likely exceeds what is practical for reliable tool selection. Although the server's scope is broad, many advanced modeling and report-design operations could be grouped or layered behind fewer entry points.

    Completeness3/5

    The surface covers many lifecycle stages including connection, modeling, reporting, deployment, Git sync, security, and governance. However, there are notable gaps: no delete/remove operations for measures, visuals, roles, or workspace items, and no list/browse/discovery tools for workspaces, datasets, or reports, creating dead ends for common workflows.

    Maintenance

    ActivityNo data
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      B
      quality
      D
      maintenance
      Enables AI assistants to interact with Microsoft Fabric and Power BI services through the Model Context Protocol. Users can manage workspaces, execute DAX queries, refresh datasets, and create Fabric notebooks using natural language.
      6
      9 npm
      2
      MIT
    • A
      license
      B
      quality
      B
      maintenance
      Enables AI agents to interact with Microsoft Fabric Real-Time Intelligence services, allowing for seamless data querying, analysis, and streaming capabilities.
      39
      5,519 PyPI
      133
      MIT
    • A
      license
      B
      quality
      A
      maintenance
      Enables AI agents to author and edit Power BI files locally (.pbix/PBIP), covering semantic models, reports, and Power Query M with 490 tools.
      100
      23 npm
      3
      Cryptographic Autonomy 1.0 (Combined Work Exception)