Skip to main content
Glama
HorizunGroup

Horizun PBI MCP

Official
by HorizunGroup

pbi_export_pbix

Convert a .pbip project into a real .pbix or .pbit by using Power BI Desktop's official Save As flow. It checks the model, controls refresh, and verifies the saved output.

Instructions

Exporta el proyecto .pbip a un archivo .pbix (o .pbit) de verdad.

Microsoft no publica ninguna API para convertir el formato, asi que esto automatiza el flujo OFICIAL: abre el proyecto en Power BI Desktop y usa Archivo > Guardar como. No se fabrica el .pbix a mano -un zip cosido con TOM abre a veces y rompe otras-.

Antes de tocar Desktop se resuelve la ruta exacta, se valida el TMDL, se comprueba que el destino cabe en Windows y, si existe y pasas overwrite=true, se respalda. Si el destino existe y no lo pasas, falla ANTES de abrir ninguna ventana.

refresh: 'auto' intenta refrescar y declara el resultado sin adornarlo; 'required' no exporta si no pudo refrescar -para no entregar un .pbix como si tuviera datos-; 'skip' guarda el estado que el modelo tenga ahora.

Que el dialogo desaparezca NO es que se haya guardado: se comprueba que el archivo existe, que es .pbix y no .pbit, que pesa mas de cero, que su fecha es de esta ejecucion y que el lector de .pbix lo puede abrir con informe y modelo dentro. Si saved_as_verified no es true, la respuesta no es un exito.

leave_open=true (por defecto) deja abierto exactamente el .pbix generado y lo selecciona como modelo activo. Nunca cierra una ventana que no abrio esta operacion. La respuesta trae desktop_session (desktop_pid + desktop_started): es lo que acepta pbi_close_desktop para cerrar ESA ventana despues, porque ya no responde a la ruta del .pbip original.

format: 'pbix' (por defecto) o 'pbit'. Con 'pbit' se elige el tipo de PLANTILLA en el mismo Guardar como, se atiende el dialogo de descripcion que Desktop abre despues y se verifica que el archivo tenga forma de plantilla: informe y definicion del modelo, SIN datos. No se fabrica quitando partes de un .pbix.

Antes de conducir la ventana se espera a que su titulo muestre el documento pedido (hasta 90 s): Sin titulo es Desktop cargando, no otra ventana. Un titulo estable de OTRO documento se rechaza.

project_path es un alias de pbip_path; si llegan distintos, la tool devuelve un conflicto en vez de elegir uno.

Requiere Windows, Power BI Desktop instalado y el extra export (pip install "horizun-pbi-mcp[export]"). El cuadro de guardado se conduce por UI Automation desde un proceso aparte: los mensajes Win32 cambian lo que se LEE en el desplegable de tipo sin avisar a la aplicacion, y Desktop sigue guardando un proyecto. pbi_capabilities dice en pbix_export si esta disponible aqui y ahora.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNopbix
refreshNoauto
timeoutNo
out_pathNo
overwriteNo
pbip_pathNo
leave_openNo
request_idNo
project_pathNo
confirm_reuseNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.1.1
    • addedInput schema / properties / format
      Added value: +{
      +  "default": "pbix",
      +  "title": "Format",
      +  "type": "string"
      +}
    • addedInput schema / properties / project_path
      Added value: +{
      +  "default": "",
      +  "title": "Project Path",
      +  "type": "string"
      +}
  2. Addedv2.1.0

TDQS

A4.5/5.0
Behavior5/5

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

The description goes far beyond the boolean annotations: it discloses that the tool drives Power BI Desktop's Save As dialog via UI Automation, performs pre-flight validation, backs up existing destinations only when overwrite=true, and fails before opening any window if the destination exists without overwrite. It also explains verification after the dialog closes, the exact meaning of saved_as_verified, the leave_open behavior, desktop_session semantics for pbi_close_desktop, and the pbit template verification path. This is exceptional transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured, with the core purpose front-loaded and distinct paragraphs for refresh semantics, verification, leave_open behavior, format choice, and window handling. Most sentences carry meaningful caveats or safety information, though the length is substantial and a few details could arguably live in the parameter schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex automation tool with 10 parameters, no schema descriptions, and meaningful failure modes, the description covers prerequisites, validation, verification, session handling, and capability checks. The missing parameter explanation for timeout, request_id, and confirm_reuse, plus the only-implied out_path meaning, prevents it from being fully complete.

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

Parameters4/5

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

With 0% schema description coverage, the description compensates well by explaining format, refresh, overwrite, leave_open, pbip_path/project_path alias behavior, and conflict handling when both alias values are provided. It does not explicitly explain timeout, request_id, or confirm_reuse, and out_path is only implied through 'destino', so the coverage of all ten parameters is not complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb+resource statement: 'Exporta el proyecto .pbip a un archivo .pbix (o .pbit) de verdad.' It clearly identifies the source format, target format, and the deliberate approach (official Save As flow), and distinguishes itself from a hand-crafted zip conversion. This is unambiguous and separates it from sibling tools like pbi_convert_pbix_to_pbip and pbi_backup_pbip_project.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear contextual guidance: this is for producing a real .pbix/.pbit from a .pbip when no official API exists, and it states the environment prerequisites (Windows, Power BI Desktop, the 'export' extra) and how to check availability via pbi_capabilities. It does not explicitly name when-not-to-use alternatives such as pbi_convert_pbix_to_pbip or pbi_open_in_desktop, so it stops just short of a 5.

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

Deploy Server

Other Tools