Skip to main content
Glama
HorizunGroup

Horizun PBI MCP

Official
by HorizunGroup
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

pbi_open_and_refresh

Destructive

Open a Power BI project and refresh its data in one call, eliminating the need to run two separate steps to get a useful session with loaded data.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo
pathNo
typeNofull
tablesNo
confirmNo
timeoutNo
pbip_pathNo
request_idNo
reuse_openNo
fit_to_pageNo
project_pathNo
refresh_timeout_secondsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.1.1
    • addedInput schema / properties / fit_to_page
      Added value: +{
+  "default": false,
+  "title": "Fit To Page",
+  "type": "boolean"
+}
    • addedInput schema / properties / page
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Page"
+}
    • addedInput schema / properties / project_path
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Project Path"
+}
  2. Changed6 schema fields changedv2.0.2
    • addedInput schema / properties / confirm
      Added value: +{
+  "default": false,
+  "title": "Confirm",
+  "type": "boolean"
+}
    • addedInput schema / properties / path / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / path / default
      Added value: +null
    • removedInput schema / properties / path / type
      Removed value: -"string"
    • addedInput schema / properties / pbip_path
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Pbip Path"
+}
    • removedInput schema / required
      Removed value: -[
-  "path"
-]
  3. Changed1 schema field changedv1.5.1
    • addedInput schema / properties / refresh_timeout_seconds
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Refresh Timeout Seconds"
+}
  4. Addedv1.2.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only indicate destructive=true, but the description adds substantial behavioral detail: refresh discards unsaved memory, failed refresh leaves the window open deliberately, existing sessions are reused, page/fit_to_page changes happen via UI Automation, and unverifiable results are reported in warnings rather than assumed. This goes well beyond the annotations.

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 organized into focused paragraphs, and most details earn their place: rationale, failure behavior, parameter aliases, and UI Automation caveats. Some sections are dense and could be tightened, but nothing feels purely redundant.

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 the core default workflow, the description is thorough: it covers the combined behavior, active-project fallback, return equivalence, confirm requirement, failure handling, and optional page/fit_to_page effects. Missing semantic detail for several optional parameters prevents a perfect score, but the output schema and clear defaults mitigate the gap.

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

Parameters3/5

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

With 0% schema description coverage, the description does explain several parameters meaningfully: path/pbip_path are aliases and can be omitted, reuse_open controls session reuse, confirm is required, and page/fit_to_page affect post-refresh navigation. However, type, tables, timeout, request_id, project_path, and refresh_timeout_seconds are left undocumented in both schema and description, leaving gaps for non-default usage.

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 specific verb and resource: 'Abre el proyecto en Power BI Desktop y lo refresca, en una llamada.' It clearly states this tool performs the combined open-and-refresh workflow, which distinguishes it from sibling open-only or refresh-only tools.

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 explains that opening without refreshing is useless because a newly opened .pbip has no data, and that this was previously always two separate calls. This implies when to prefer this combined tool over separate open/refresh calls, though it does not explicitly name those sibling tools or state when NOT to use it.

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