powerbi-orchestrator-mcp
It lets an LLM orchestrate Power BI/Fabric work end-to-end through 31 high-level MCP tools.
Connect to Power BI Desktop, Fabric workspaces, PBIP folders, and PBIX files.
Plan, dry-run, approve step-by-step, apply, and roll back multi-step changes.
Create and modify semantic models from schema/TMDL, add validated DAX measures, diff models, and generate data dictionaries.
Refactor DAX and model design with measure simplification, duplication detection, name abbreviation, and calculation groups.
Author and edit PBIR reports: scaffold pages, edit visuals, recommend KPI visuals, design pages from briefs, and capture screenshots.
Audit quality, BPA rules, DAX lint, naming, WCAG accessibility, UX/storytelling, and report performance.
Apply accessibility themes and alt-text backfills, then re-audit.
Operate Fabric/Power BI Service: deploy with gates, refresh datasets, promote pipeline stages, set RLS, apply sensitivity labels, and sync Git/workspace.
Run DAX queries and regression tests against live datasets, with row limits and baseline comparisons.
Diagnose server health and available modeling engines.
Default to safe behavior: dry-run writes/deploys/refreshes, workspace-contained paths, read-only mode, per-tool scopes, and audit trails.
Provides Git integration for Power BI/Fabric, enabling version-controlled management of Power BI items by committing a Fabric workspace to a local Git repository and syncing a Git-based PBIP tree back to a Fabric workspace.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@powerbi-orchestrator-mcp Validate the semantic model in my Sales.pbip for star schema and BPA issues."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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.
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.pyThat'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.mdy 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 |
|
|
|
|
|
|
|
|
|
|
|
|
| no ejecuta sin dataset | pasar |
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 equivalentesAZURE_*) 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_ROOTconfigurado es la frontera y nada lo ensancha;PBI_ALLOW_OUTSIDE_WORKSPACE_READ=1la 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--readonlyen 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 conTools.Admintampoco 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_querydevuelve 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 requierenTools.Admin;Tools.Adminconcede 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_idno alcanza.Plugins desactivados por defecto. Cargar un plugin ejecuta Python arbitrario, así que requiere
PBI_ENABLE_PLUGINS=1y 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_regressionfalla si no encuentra el baseline: sin baseline no hay nada contra qué comparar.apply_plandistinguerolled_backderollback_partialy derollback_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í.
Quick links
examples/— 3 workflows reproducibles (safe rename, deploy, audit loop).CHANGELOG.md— condensed changelog.CONTRIBUTING.md— dev setup, testing, release process.SECURITY.md— how to report vulnerabilities.docs/troubleshooting.md— common errors with remediation.SPEC.md— visión, arquitectura 6 capas, MVP ambicioso.docs/releases/RELEASE-NOTES-v1.23.1.md— última release con decisiones.docs/architecture.md— arquitectura detallada.docs/engines-setup.md— instalar engines opcionales.docs/connect-target.md— uso del entry-point tool.specs/— specs modulares por capa + por tool.docs/MVP-STATUS.md— estado de implementación.
Instalación
1. Instalar el orquestrador (Python)
pip install powerbi-orchestrator-mcpEl 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 TabularEditorLos 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 Desktopplan_change— crear un plan versionableapply_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 equivalenteabstract_measures— la lógica que está escrita más de una vezabbreviate_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.
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.
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 pasadaEl bucle es el punto: auditar, corregir, auditar otra vez. La segunda pasada es la que dice si el arreglo funcionó.
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_reportypython_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.Adminpara las operaciones de gobernanza✅ Lecturas y escrituras acotadas al workspace (
PBI_WORKSPACE_ROOT)✅ Planes con dueño: conocer el
plan_idno 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=1deja 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
powerbi-modeling-mcp— Microsoft (EULA restrictiva)superbi-mcp— cyphonica (FSL, no commercial)te— Tabular EditorMCP spec: modelcontextprotocol.io
Available Tools
31 toolsabbreviate_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
Scored across 31 tools
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.
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).
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.
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
Related MCP Connectors
One place to build, share, and govern the skills and tools your AI agents use at work.
214 tools for AI agents over one MCP endpoint: image, video, audio, 3D, data, storage, mail, GPUs.
Agent-native security, trust, reliability, data and procurement tools for AI workflows.
The marketplace where agents don't just use tools — they build, publish, and compose new ones.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables 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.69 npm2MIT
- AlicenseBqualityBmaintenanceEnables AI agents to interact with Microsoft Fabric Real-Time Intelligence services, allowing for seamless data querying, analysis, and streaming capabilities.395,519 PyPI133MIT
- FlicenseNot gradedqualityDmaintenanceEnables AI agents to deploy Power BI reports to Microsoft Fabric by automating data loading from CSV, creating semantic models, and generating report visuals.1-
- AlicenseBqualityAmaintenanceEnables AI agents to author and edit Power BI files locally (.pbix/PBIP), covering semantic models, reports, and Power Query M with 490 tools.10023 npm3Cryptographic Autonomy 1.0 (Combined Work Exception)