Horizun PBI MCP

Duplica una pagina con todos sus visuales, en una sola transaccion. Se regeneran los identificadores que deben ser unicos (el de la pagina y el de cada visual) y se conserva todo lo demas.

Duplica un visual conservando campos, formato y filtros. Solo se regenera el identificador, que debe ser unico. La copia se desplaza `offset_x`/`offset_y` para que no quede tapando al original. `target_page` permite copiarlo a otra pagina.

Exporta la informacion disponible a un libro Excel verificado. Crea hojas para resumen, tablas, columnas, medidas, relaciones y, si hay PBIP activo, paginas, visuales y auditoria. `source` admite `auto|live|pbip`. Si se proporciona `query`, ejecuta DAX de solo lectura contra Desktop y agrega `Datos_DAX`, declarando cualquier truncamiento. El archivo se escribe en `outputs/excel/`, nunca dentro del PBIP. No sobrescribe nombres existentes, neutraliza formulas inyectadas y vuelve a abrir el XLSX antes de informar exito.

Exporta una MAQUETA HTML de una pagina EXISTENTE (layout + campos de cada visual).

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_pa…

Exporta el CONTENIDO del informe: los datos que muestra el tablero. A diferencia de `pbi_export_excel` y `pbi_generate_pdf_report`, que documentan el proyecto, esto exporta lo que el cliente ve. `select` admite tres formas, combinables: - `pages`: ["Matriz de Riesgos"] -> la tabla que hay detras de CADA visual de esas paginas (por nombre visible o id interno). - `visuals`: ["15b0fc11e628..."] -> solo esos visuales. - `queries`: [{name, rows:["Tabla[Columna]"], values:["Medida"], filters:[{field, values, exclude?}], top_n?}] -> lo que el cliente declare, sin referirse a ningun visual. Cada consulta se reconstruye a partir de los campos del visual, se ejecuta en SOLO LECTURA contra el modelo en vivo y sale como una hoja de Excel (`format`: `xlsx|pdf|both`). Necesita el modelo en vivo: los datos solo existen en el motor, no en el .pbip. Con `auto_open` abre el informe en Desktop si hace falta, y se NIEGA a exportar si el modelo esta abierto pero sin procesar, en vez de publicar un archivo en blanco. Con `dry_run` devuelve el DAX que ejecutaria sin tocar el motor ni escribir nada. Cada hoja declara con que filtros se saco y, sobre todo, cuales no se pudieron aplicar. Los visuales sin consulta tabular -textos, imagenes, formas- se listan aparte con el motivo.

El ULTIMO paso de una construccion: del proyecto al entregable. Hace de extremo a extremo lo que hasta ahora eran cinco llamadas y un par de suposiciones: resuelve el archivo exacto que le pasas, lo prepara -convirtiendolo si le das un .pbix-, valida el proyecto, exporta a .pbix conduciendo Power BI Desktop, inspecciona el resultado y deja abierto justo el entregable, seleccionado como modelo activo. Una sola respuesta verificable: `output_pbix`, `output_sha256`, `output_size`, `saved_as_verified` y `opened_path_verified`. `path` (o su alias `project_path`) se puede omitir para usar el proyecto activo. `format`: 'pbix' o 'pbit' (plantilla: informe y definicion del modelo, sin datos; producida por el propio `Guardar como` de Desktop, nunca fabricada a mano). Requiere Windows con Power BI Desktop instalado. `confirm_reuse=true` autoriza conducir una ventana que ya estaba abierta por el usuario. Sin esa autorizacion el flujo falla cerrado, igual que `pbi_export_pbix`.

Genera un borrador de spec a partir de un preset y unos campos. `preset`: executive | financial | sales | operations | evm | detail. `measures`: medidas para los KPIs y los graficos. `category`: columna para el eje de los graficos. El resultado es un spec editable: revisalo y pasalo por pbi_validate_page_spec.

Genera un PDF ejecutivo, tecnico o de auditoria con capturas. Compone informacion existente del modelo, paginas, visuales y auditoria. `capture_paths` acepta hasta 20 PNG/JPEG, por ejemplo las rutas devueltas por `pbi_validate_desktop_render`. No inventa graficas si no hay captura. El PDF se reabre con pypdf y, cuando Poppler esta disponible, su primera pagina se renderiza a PNG como prueba visual. Se guarda en `outputs/pdf/`.

Genera una pagina con visuales propuestos a partir del modelo. Revisa el modelo, valida los campos sugeridos (no inventa campos), crea la pagina, agrega tarjetas para medidas y un grafico por categoria, y acomoda todo con el layout indicado. Devuelve un resumen de lo creado.

Documentacion tecnica completa en Markdown, guardada en outputs/. Incluye el modelo (tablas, medidas con su DAX y dependencias), el informe pagina a pagina con los campos de cada visual, y la auditoria con puntaje por dominio.

Lee el brief de intencion del proyecto activo. Devuelve `defined: false` si no existe —con las preguntas que hay que hacerle al usuario para definirlo—, o el brief completo y el sistema de diseño que recomienda. Consultalo ANTES de proponer paginas o elegir sistema: es la diferencia entre servir al proposito del tablero y deducirlo todo del modelo.

Devuelve un objeto del modelo con todo su detalle. `kind`: table | column | measure. Para una columna usa 'Tabla[Columna]'. En una medida incluye ademas las referencias que aparecen en su DAX.

Lee la consulta Power Query (M) de una particion o expresion. En un .pbip el M no tiene archivo propio: vive dentro del TMDL, en la `partition` de cada tabla y en `expressions.tmdl`. Esta tool lo saca tal cual, con su SHA-256, que es lo que despues acepta `pbi_update_power_query` como `expected_sha256` para no escribir sobre una version que ya cambio. `source`: 'pbip' (TMDL en disco), 'live' (motor de Desktop, DMV `TMSCHEMA_PARTITIONS` / `TMSCHEMA_EXPRESSIONS`) o vacio: pbip si hay proyecto activo, si no el modelo vivo. Con `live` la respuesta trae `file: null` y `source: 'live'`: es la definicion cargada en Desktop, no el archivo. `table` + `name` seleccionan una particion; `name` con `kind='expression'`, una expresion con nombre. `object_name` es un alias de `name` (si llegan distintos, conflicto). Si la seleccion queda ambigua o no existe, el error trae la lista de candidatos. Solo lectura, y solo lectura de TEXTO: nadie ha ejecutado esta consulta. No hay motor M fuera de Power BI Desktop.

Definicion completa y normalizada de un visual. Devuelve tipo, posicion, orden Z, titulo, campos por rol, medidas y columnas referenciadas, si tiene formato propio, sus filtros, y la definicion cruda por si hace falta inspeccionarla.

Estado general del servidor: dependencias, DLLs, sesion y proyecto. Solo lectura. Es lo primero que conviene llamar: dice si la capa EN VIVO esta disponible, si hay un proyecto .pbip abierto y si algo requiere atencion (sesion obsoleta, journals pendientes).

Oculta/muestra VARIAS columnas como un solo lote. `columns`: lista de {"table": ..., "column": ...}. Valida todas las entradas antes de escribir: si alguna tabla o columna no existe, no se modifica nada y el error indica el indice. Los archivos TMDL se escriben en una sola transaccion y el modelo en vivo con un solo SaveChanges. `count` es el numero de entradas SOLICITADAS (incluidos duplicados); `results` trae una entrada por cada una, en el mismo orden. mode='both' esta temporalmente deshabilitado bajo la politica estricta: 'live' necesita Power BI Desktop abierto y 'pbip' lo necesita cerrado, asi que una sola llamada aplicaria solo uno de los dos destinos. Elige 'live' o 'pbip', o usa 'auto' y se mira el estado para elegir. Si estas construyendo desde cero, 'auto' o 'pbip': el defecto es 'live' y exige Desktop abierto.

Inspecciona un journal y lo compara con el estado ACTUAL del proyecto. Solo lectura: no restaura nada. Por cada archivo dice si sigue como el original, si hay respaldo disponible y cual fue su desenlace. `journal`: ruta devuelta por pbi_list_pending_journals.

Radiografia de un .pbix SIN convertirlo ni abrir Power BI Desktop. Dice en que formato esta el informe ('pbir' si ya trae el formato mejorado y solo hay que copiarlo, 'layout' si es el heredado y hay que traducirlo), si lleva modelo de datos propio o es un informe con conexion en vivo, y cuantas paginas, recursos y visuales personalizados tiene. Sirve para saber que esperar antes de lanzar la conversion. `path`: ruta al archivo .pbix. Es el UNICO nombre del parametro: no hay alias `pbix_path`, porque `path` es obligatorio en el contrato congelado y un alias no podria sustituirlo.

Catalogo de reglas de auditoria disponibles, con su dominio y severidad.

Reglas que tienen correccion automatica, y en que consiste cada una.

Marcadores del informe, y los que no cuadran entre indice y disco. Un marcador que no esta en el indice no se muestra; una entrada del indice sin archivo rompe el panel. Los dos casos son mudos al abrir.

Lista los .pbix de una carpeta y como se convertiria cada uno. Recorre los archivos sin abrirlos en Desktop y dice, por cada uno, si el informe se copiaria (ya esta en PBIR) o habria que traducirlo, y si hace falta Desktop para sacar el modelo. Es la vista previa del lote. `path`: carpeta (o un .pbix suelto). `recursive`: incluir subcarpetas.

Sistemas de diseno disponibles: para que sirve cada uno y que trae. Un sistema decide a la vez el tema (color y tipografia, con paletas ya verificadas contra daltonismo), el tamano del lienzo, la rejilla sobre la que se coloca todo y la escala de texto. Son la misma decision: un tablero de sala se lee a cuatro metros y uno en PDF a cuarenta centimetros, y eso no es el mismo diseno con otro color. Eligelo ANTES de la primera pagina; cambiarlo despues obliga a recolocarlo todo.

Lista los modelos de Power BI Desktop abiertos localmente. Detecta el motor de Analysis Services (localhost:<puerto>) de cada informe abierto y devuelve puerto, connection string, catalogo y nº de tablas. Cada instancia trae ademas su IDENTIDAD: `engine_pid` es el proceso del motor (msmdsrv.exe) y `desktop_pid` el de la ventana (PBIDesktop.exe) —son distintos—, mas el titulo de la ventana, la ruta del documento cuando puede demostrarse, `identity_confidence` y la `identity_evidence` que la sostiene. Un .pbip no deja descriptor abierto sobre su carpeta: ahi la ruta sale `null` en vez de adivinada.

Lista las jerarquias del modelo con sus niveles y columnas.

Lista medidas con tabla, expresion DAX, formato, descripcion y carpeta. **Empieza por `detail='summary'`.** Omite la expresion DAX, que es el grueso del peso y rara vez hace falta para orientarse; para leer el DAX de una medida concreta usa `pbi_get_object`, y para buscar dentro del DAX, `pbi_search_model`. `detail='full'` sigue siendo el valor por defecto por compatibilidad. `tables`: acota a las medidas de esas tablas.

Presets de pagina disponibles, con los bloques que compone cada uno. Un preset describe la INTENCION de la pagina (KPIs arriba, grafico protagonista, detalle abajo). Los campos concretos los eliges tu.

Lista las particiones por tabla (modo de almacenamiento y origen). Con `source='live'` se leen del motor (DMV `TMSCHEMA_PARTITIONS`): tabla, nombre, tipo de origen (m, calculated...), modo (import, directQuery, dual...), estado y hora del ultimo refresco. Aparte, en `expressions`, las consultas COMPARTIDAS (`TMSCHEMA_EXPRESSIONS`: parametros y funciones M), que no pertenecen a ninguna tabla. Con `source='pbip'` se leen del TMDL en disco. El texto M no viaja aqui: lo da `pbi_get_power_query`.

Lista los journals del proyecto activo. Un journal `pending` es el de una operacion que ni se confirmo ni se revirtio (el proceso murio en medio). Contiene los originales. `only_pending=false` lista tambien los ya cerrados.

Lista las perspectivas del modelo. Requiere la capa EN VIVO: el lector TMDL de este proyecto no las extrae. Si no hay ninguna, devuelve una lista vacia con la explicacion.

Lista relaciones: tablas/columnas, cardinalidad, filtro cruzado y estado.

Lista las paginas del informe PBIR activo (id, nombre, tamano, nº visuales).

Recursos del informe: declarados, en disco y los que no cuadran. Un archivo sin declarar no lo encuentra Power BI; una declaracion sin archivo deja el visual vacio. Los dos casos son invisibles al abrir el informe, asi que se listan aparte.

Lista los roles de seguridad (RLS) y sus filtros por tabla.

Lista tablas con columnas, tipos, visibilidad y conteos. `source`: 'live' (modelo abierto, por defecto) o 'pbip' (archivos TMDL). **Empieza por `detail='summary'`.** Devuelve nombre, visibilidad y recuentos, sin la lista de columnas. Con `detail='full'` (por defecto, por compatibilidad) un modelo de siete tablas ocupa ~28.000 caracteres y uno corporativo puede llenar buena parte de la ventana de contexto en una sola llamada. `tables`: acota a esas tablas por nombre. Es lo que se usa despues del resumen para pedir el detalle solo de las que interesan. Un nombre que no existe falla y devuelve los disponibles, en vez de una lista vacia.

Temas de informe disponibles, con su paleta y para que sirve cada uno. Devuelve, por tema: el escenario de uso, el color de fondo, los colores de serie EN SU ORDEN (el orden es lo que garantiza que dos series contiguas se distingan tambien con daltonismo) y los colores de estado. Usalo para PROPONER un esquema antes de construir, en vez de decidirlo por el usuario.

Lista los visuales de una pagina: id, tipo, posicion, campos, titulo. `page`: id interno o nombre visible de la pagina.

De que depende una medida y quien depende de ella. Devuelve dependencias directas (medidas, columnas y referencias ROTAS), el cierre transitivo sobre medidas hasta `depth`, y la lista de medidas que la usan. Analisis lexico: detecta referencias escritas, no las construidas dinamicamente.

Resumen compacto del modelo, pensado para leerlo de un vistazo. Conteos, tablas con su tamano, medidas por tabla, columnas calculadas, tablas desconectadas, relaciones bidireccionales y referencias rotas. Es la primera tool que conviene llamar para orientarse en un modelo. `source`: 'live' (Desktop abierto) o 'pbip' (archivos TMDL).

Corrige lo corregible de una pagina sin reacomodarla entera. Mete dentro del lienzo lo que se sale, sube al minimo lo demasiado pequeno y respeta los margenes. NO mueve lo que ya esta bien: es una correccion conservadora. `dry_run=true` devuelve el plan sin escribir.

Normaliza la geometria de TODAS las paginas del informe. Mete dentro del lienzo lo que se sale, sube al minimo lo demasiado pequeno y respeta margenes. No reacomoda lo que ya cumple. Compara el puntaje de auditoria antes y despues.

Abre el proyecto en Power BI Desktop y lo refresca, en una llamada. Es la secuencia real de trabajo y siempre eran dos llamadas de unos catorce segundos cada una, porque un `.pbip` recien abierto trae el modelo SIN DATOS: abrirlo sin refrescar no sirve para comprobar nada. `path` y `pbip_path` son el mismo parametro -el segundo es como lo llama `pbi_session_info`-, y se pueden omitir los dos: entonces se usa el proyecto .pbip activo. Devuelve lo mismo que las dos por separado, incluido `rows_by_table`. Si el archivo ya estaba abierto se reutiliza esa sesion (`reuse_open`). Si el refresh falla, la ventana se DEJA ABIERTA: ya cargo bien, y cerrarla borraria justo el contexto que hace falta para ver por que fallo. Sale en `desktop_left_open`. `page` y `fit_to_page` (opcionales) eligen, DESPUES de refrescar, la pestaña de esa pagina y la vista "Ajustar a la pagina" en la propia ventana, por UI Automation, sin tocar `pages.json`. Mueven la ventana igual que el refresh la vacia: los cubre el mismo `confirm=true`. La respuesta trae `navigation` con `verified` por accion y, en el zoom, `verified_means` con lo que esa prueba alcanza: que el nivel de zoom cambio, no que el modo resultante sea el pedido. Lo que no se pudo demostrar se dice en `warnings`, no se da por hecho. **Exige `confirm=true` desde 2.0.0.** Abre una aplicacion y refresca: los dos efectos son visibles y el segundo descarta lo que hubiera en memoria sin guardar.

Abre un .pbip o .pbix en Power BI Desktop y espera a que sirva el modelo. Cierra el ciclo de trabajo: despues de editar un proyecto, esto permite comprobar que ABRE de verdad y consultar sus medidas, sin pedirle al usuario que lo haga a mano. Un TMDL que no carga se manifiesta aqui. Espera a que el motor local aparezca y deje de crecer, identifica cual de las instancias corresponde a este archivo (el puerto es dinamico) y, con `select=true`, lo deja como modelo activo. Si el archivo ya estaba abierto se reutiliza esa sesion y no se toca nada (`reuse_open`). Nunca cierra una ventana del usuario. `path` (o `pbip_path`, como lo llama `pbi_session_info`, o `project_path`) se puede omitir: entonces se abre el proyecto .pbip activo. Tambien acepta la CARPETA del proyecto si contiene un unico `.pbip`; con varios, dice cuales hay y no elige. Ojo: un .pbip recien abierto trae el modelo SIN DATOS. Refresca despues con pbi_refresh_model si vas a comprobar valores.

Abre un proyecto .pbip y lo marca como proyecto activo. Detecta carpetas .SemanticModel (TMDL) y .Report (PBIR) y devuelve un resumen con advertencias (p.ej. si el informe no usa PBIR). `path`: ruta al archivo .pbip o a su carpeta.

Entrega el material para diseniar una hoja: modelo (tablas/medidas/columnas), catalogo de visuales existentes (reutilizables como plantilla), canvas y paginas. Usa esto ANTES de proponer una hoja: te dice que campos y tipos de visual hay.

Planifica correcciones para reglas CONCRETAS. No escribe nada. No existe "arreglar todo": hay que indicar `rules` explicitamente. `objects` acota mas todavia (ids de visual o de pagina). Devuelve las acciones exactas que se aplicarian, con su motivo.

Calcula un PLAN sin aplicar nada, y devuelve un `plan_token`. `operation`: una de las que lista pbi_capabilities en `planned_operations`. `arguments`: los mismos que aceptaria la tool. El plan incluye el diff por archivo y una huella del estado sobre el que se calculo. Si el proyecto cambia despues, pbi_apply_plan lo rechaza.

Checklist de pre-entrega con plan de correccion. Audita el proyecto, produce un checklist de bloqueantes y propone las correcciones automaticas disponibles. Con `dry_run=false` las aplica y compara el puntaje antes y despues.

Deja listo EXACTAMENTE el proyecto que le pasas, y dice cual es. Es el punto de entrada de una sesion de trabajo. Acepta las tres cosas que una persona tiene a mano y las resuelve con una sola politica: - un `.pbip`: se valida y se activa esa ruta, tal cual; - un `.pbix`: se convierte ESE archivo y se activa el `.pbip` que produjo la conversion (no uno que se le parezca en la carpeta); - una carpeta: solo se resuelve si contiene UN candidato. Con dos `.pbip` falla con `ambiguous_pbip_project` y te los enumera, porque elegir el primero por orden alfabetico es como se acaba editando el proyecto equivocado con la respuesta en verde. La ruta que pasas gana siempre: sobre el proyecto activo, sobre la sesion restaurada y sobre lo que tenga abierto Power BI Desktop. Si algo falla, el proyecto activo se queda como estaba. La respuesta trae `requested_path`, `resolved_path`, `selection_reason`, `path_match`, `previous_active_project` y `active_project`, para que la decision sea auditable sin repetirla. `open_result=true` abre el resultado en Desktop y comprueba que la ventana sirve ese archivo.