Power BI Desktop Bridge: qué es y qué cambia para los agentes
Durante años, Power BI Desktop ha sido una caja cerrada. Podías abrirle el modelo por el puerto de Analysis Services, sí, pero el informe en sí solo se tocaba con el ratón. El Power BI Desktop Bridge, que Microsoft acaba de sacar en vista previa, cambia eso: es un servidor local que vive dentro del propio proceso de Desktop y deja que un script o un agente le pregunte qué tiene abierto, le pida que recargue el fichero y le saque una captura de la página.
Parece poco. No lo es. Es justo la pieza que faltaba para que un agente pueda construir un informe y comprobar que le ha salido bien, en vez de limitarse a describir lo que cree que ha hecho.
Qué es exactamente el Power BI Desktop Bridge
Técnicamente es un canal de comunicación entre procesos, un named pipe de Windows con el nombre pbi-desktop-bridge-{processId}, que habla JSON-RPC 2.0. Cada ventana de Desktop abierta tiene el suyo. Solo funciona en la máquina local; no hay acceso remoto y Microsoft lo dice de forma explícita.
Se activa desde una opción de vista previa llamada «Enable external tool access to Power BI Desktop through secure local APIs». Viene marcada por defecto, así que si tienes una versión reciente de Desktop es probable que el puente ya esté ahí esperando.
Un detalle que conviene saber antes de programar contra él: admite varios clientes conectados, pero solo ejecuta una operación a la vez. Si mandas una petición mientras otra está en curso, devuelve error. No hay cola. El cliente tiene que esperar.
Los cuatro métodos que expone hoy
| Método | Qué hace | Para qué sirve de verdad |
|---|---|---|
bridge.manifest | Devuelve la lista de métodos con sus esquemas de entrada y salida | Descubrir qué soporta esa versión concreta de Desktop antes de llamar a nada |
application.state.get/v1 | Ruta del fichero abierto y si tiene cambios sin guardar | No pisar el trabajo de alguien recargando encima de cambios pendientes |
file.reload/v1 | Recarga el PBIP desde disco, con o sin la definición del modelo | Aplicar ediciones externas sin cerrar y abrir Desktop |
report.snapshot.capture/v1 | Captura PNG de una página, con escala de 1 a 3 | Ver el resultado real, no el que el agente imagina |
El manifiesto merece una nota aparte. Que la API se describa a sí misma es lo que permite que un agente se adapte a la versión que se encuentra en vez de romperse con un MethodNotFound. Es el mismo principio que en MCP, donde el servidor le cuenta al modelo qué herramientas tiene, y lo explicamos en tu ERP como servidor MCP.
El bucle que lo cambia todo
Los cuatro métodos por separado son modestos. Juntos forman un ciclo:
- El agente edita los ficheros del proyecto PBIP en disco: añade un visual, cambia un formato, mueve una página.
- Pide a Desktop que recargue.
- Captura la página.
- Mira la captura y decide si lo que ha hecho se parece a lo que se le pidió.
- Si no, vuelve al paso uno.
Ese paso cuatro es el que hasta ahora no existía. Un agente podía generar un JSON de informe impecable en apariencia y dejar un visual fuera de la página o con la fuente en blanco sobre blanco, y nadie lo sabía hasta que un humano abría Desktop. Ahora el propio agente lo ve.
Microsoft ha construido encima su Report Authoring Skill, publicada en el repositorio skills-for-fabric, y también una CLI en npm, @microsoft/powerbi-desktop-bridge-cli, con comandos como status, reload, screenshot y screenshot-all. Nosotros ya la tenemos en el flujo de Claude Code para proyectos PBIP propios, y la diferencia entre trabajar con y sin captura es la diferencia entre revisar el resultado y revisar la intención.
Límites del Power BI Desktop Bridge en vista previa
Está en preview y se nota. Antes de montar nada encima, conviene tener claro qué no hace todavía.
- La edición externa y la recarga funcionan con proyectos PBIP, no con ficheros
.pbix. Si sigues en pbix, este es el empujón definitivo para migrar. - La recarga es completa: informe entero, modelo entero o los dos. No recarga un visual suelto.
- Recargar resetea los filtros y parte del estado de la interfaz.
- Hay ficheros que durante la preview no se pueden editar desde fuera:
definition.pbir,report.json,mobileState.jsonysemanticModelDiagramLayout.json. - No recarga
cache.abf. - Si el proyecto tiene un
unappliedChanges.jsonpendiente, aplícalo antes de tocar expresiones del modelo desde fuera. Si no, Desktop descarta tus cambios externos al aplicar los suyos. - Una operación a la vez, sin cola.
Y el que más nos importa por lo que hacemos: la captura es de la página tal como está renderizada en Desktop. Sirve para validar diseño y disposición. No sustituye una prueba de datos, y no te dice nada de cómo se verá ese mismo informe embebido en una aplicación con otro tamaño de contenedor.
Qué hacer con esto esta semana
Si desarrollas informes a mano, poco. Sigue igual, y quizá pruebes la CLI para hacerte capturas de todas las páginas de golpe con screenshot-all, que ya vale el precio de la entrada para documentar.
Si ya tienes agentes generando o modificando informes, o lo estás evaluando, esto cambia la conversación. La pregunta deja de ser «¿puede un agente escribir un informe?» y pasa a ser «¿puede comprobarlo?». Con el puente, sí. Escribimos sobre cómo encaja eso en una arquitectura de agentes en nuestros servicios de agentes de IA, y si tu caso es de Fabric, lo que ese agente edita acaba viviendo en el modelo del que hablamos en Direct Lake, Import o DirectQuery.
Para empezar hoy mismo: comprueba que la opción de preview está activa, instala la CLI con npm install -g @microsoft/powerbi-desktop-bridge-cli y abre un proyecto PBIP para ver qué devuelve powerbi-desktop status. Con eso ya sabes si tu versión de Desktop está preparada.
Si quieres que lo montemos contigo sobre tus informes, cuéntanos qué tienes.