Skip to main content
Glama
HorizunGroup

Horizun PBI MCP

Official
by HorizunGroup
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

pbi_close_desktop

Destructive

Close the exact Power BI Desktop instance serving a .pbip project to enable TMDL edits. Verifies process identity and confirms closure, requiring explicit confirmation to discard unsaved changes.

Instructions

Cierra la instancia de Power BI Desktop que sirve ESE proyecto.

Es la salida que faltaba del ciclo editar-abrir-mirar-editar: escribir el TMDL exige Desktop cerrado, y no habia forma de cerrarlo desde aqui -tocaba matar el proceso a mano en PowerShell-.

Cierra SOLO la instancia con ese archivo abierto, verificando la identidad del proceso (nombre + hora de arranque, nunca el PID a secas). Al final re-comprueba que el archivo ya no este abierto y lo dice en verified_closed.

DESTRUCTIVA: los cambios SIN GUARDAR de esa ventana se pierden -y en un .pbip eso incluye los datos refrescados de la sesion-. Por eso exige confirm=true. Si el archivo no estaba abierto, no hace nada y lo dice (was_open: false).

path (o pbip_path / project_path) se puede omitir: se cierra el proyecto activo, que es el que el servidor ya conoce.

Tras pbi_export_pbix(leave_open=true) la ventana queda sobre el archivo exportado y ya no responde a la ruta del .pbip original. Pasa desktop_pid y desktop_started tal cual los devuelve desktop_session de la exportacion: se cierra exactamente esa instancia, verificando nombre del proceso y hora de arranque (nunca el PID a secas, que Windows recicla). Con path ademas se exige que la ventana no este sirviendo demostrablemente otro documento.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNo
confirmNo
pbip_pathNo
request_idNo
desktop_pidNo
project_pathNo
desktop_startedNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.1.1
    • addedInput schema / properties / desktop_pid
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Desktop Pid"
+}
    • addedInput schema / properties / desktop_started
      Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Desktop Started"
+}
    • addedInput schema / properties / project_path
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Project Path"
+}
  2. Changed5 schema fields changedv2.0.2
    • 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. Addedv1.2.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only say destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=false. The description adds critical behavioral detail: it verifies process identity via name + start time, never PID alone because Windows recycles PIDs, re-checks closure and reports verified_closed, requires confirm=true before destructive action, loses unsaved changes including refreshed .pbip data, and does nothing when the file is already closed. No contradiction with annotations.

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

Conciseness5/5

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

The description is long but dense and well-structured: purpose first, then context, then destructive consequences, then parameter semantics and special export-flow coupling. Every section earns its place; there is no filler or repetition of schema/annotation information.

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

Completeness5/5

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

For a destructive tool with 7 parameters, 0 required parameters, no schema docs, and crucial safety implications, the description covers usage context, destructive side effects, confirmation requirement, identity verification, active-project fallback, export-flow passthrough, and post-condition reporting. The output schema handles the exact return shape, so nothing essential is missing.

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?

Schema description coverage is 0%, so the description carries the parameter-documentation burden. It explains that path/pbip_path/project_path are interchangeable and optional, that confirm=true is required, and that desktop_pid/desktop_started should be passed through from desktop_session after export. It does not explain request_id, and the exact numeric format of desktop_started is left implicit, so slightly below a perfect score.

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 and resource: 'Cierra la instancia de Power BI Desktop que sirve ESE proyecto' — closing the Power BI Desktop instance serving that project. It clearly distinguishes itself from sibling tools like pbi_open_in_desktop and pbi_export_pbix by emphasizing that it closes only the matching instance, not arbitrary processes.

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

Usage Guidelines5/5

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

The description explicitly names when to use this tool: when TMDL writing requires Desktop to be closed, as the missing exit from the edit-open-look-edit cycle, and after pbi_export_pbix(leave_open=true) when the window is left on an exported file. It also contrasts the manual alternative of killing the process in PowerShell and notes the no-op case when the file is not open.

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