Skip to main content
Glama
HorizunGroup

Horizun PBI MCP

Official
by HorizunGroup

pbi_create_visual

Create a visual on a specified Power BI page, configuring its type, fields, options, and position to add charts, tables, or other elements to the report.

Instructions

Crea un visual PBIR en una pagina.

visual_type acepta: actionButton, areaChart, barChart, button, card, cardVisual, clusteredBarChart, clusteredColumnChart, columnChart, donut, donutChart, funnel, gauge, htmlContent, htmlContent443BE3AD55E043BF878BED274D3A6855, image, kpi, lineChart, matrix, multiRowCard, navigation, pageNavigator, pieChart, pivotTable, rectangle, ribbonChart, scatterChart, shape, slicer, table, tableEx, text, textbox, treemap, waterfall y waterfallChart.

Para visuales con datos, valida antes de escribir los roles obligatorios, la cardinalidad maxima de cada rol y el tipo de campo admitido: dimension (Grouping), medida (Measure) o cualquiera de ambos (GroupingOrMeasure). Los elementos decorativos (texto, forma, imagen, navegador y boton) rechazan fields porque no llevan consulta.

fields: rol -> campos, p.ej. {"category":"Tabla[Col]", "values":["[Medida]"], "legend":"Tabla[Col]"}.

El rol se reconoce escrito como sea: el logico (values), el nombre que usa PBIR y que devuelve pbi_list_visuals (Values, Y, Category, Data) o un sinonimo (measure, axis). Cada campo puede ser "Tabla[Campo]" o el objeto que devuelve pbi_list_visuals, para poder leer una pagina y rehacerla sin traducir nada.

Un rol que ese tipo de visual no tiene se RECHAZA con la lista de los validos. Antes se descartaba en silencio y el visual salia sin datos.

options: formato adicional. Llaves reconocidas (una clave no reconocida se ignora, no se rechaza; ver pbi_get_visual para comprobar que quedo escrito):

  • background_color, border_color ('#RRGGBB'), background_transparency (0-100), border_radius (px): el marco de CUALQUIER visual (panel General > Efectos de Desktop). Sin background_color/border_color no se toca el marco.

  • card/cardVisual: show_category_label, value_font_size, bold_value, value_color.

  • shape: fill, transparency, text, font_size, text_color.

  • textbox: text, font_size, color, bold, font, align. El texto va en options.text, NO en fields ni en la raiz: {"type": "textbox", "options": {"text": "Resumen", "font_size": 20}}.

  • image: resource (ItemName ya registrado con pbi_add_image_resource), name, scaling.

  • pageNavigator: show_hidden, show_current.

  • actionButton: action, icon, target_page, text.

  • format: formato del VISUAL, no del contenedor. mode (segmentador: Dropdown, List, Between...), header (bool: el encabezado del campo del segmentador; false lo oculta), dataLabels (bool), legend (bool), legendPosition (Top, Bottom, Left, Right...). Una clave desconocida aqui SE RECHAZA con la lista de las validas: un formato que se pide y no se aplica deja el informe distinto de lo que se penso sin decir por que.

position: {x, y, width, height} (z opcional). Clona un visual del mismo tipo como plantilla si existe. Hace backup.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageYes
titleNo
fieldsYes
optionsNo
positionYes
request_idNo
visual_typeYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

The description discloses significant behavioral details beyond the annotations: validation of roles, rejection of unknown roles and format keys, silent ignoring of unrecognized option keys, backup creation, and template cloning. It also explains how field type constraints are enforced, giving the agent a clear mental model of side effects.

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 well-organized into sections (visual_type, fields, options, position, behavior). It starts with a clear purpose, front-loads the essential information, and each section adds necessary detail without redundancy. The length is justified by the tool's complexity and the need to disambiguate behaviors.

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?

Given the tool has 7 parameters, nested objects, and an output schema, the description covers parameter semantics, validation rules, side effects (backup), and references related tools. It is complete enough for an agent to select and invoke the tool correctly, even without seeing the output schema.

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

Parameters5/5

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

Schema description coverage is 0%, and the description completely compensates by explaining every parameter: visual_type enumerate, fields mapping format, options keys per visual type, position structure, and the role of title/request_id. It includes examples and clarifies the difference between ignored and rejected options.

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 'Crea un visual PBIR en una pagina', clearly stating the action and resource. It details the supported visual types and distinguishes itself from related sibling tools by focusing on creation with validation and options.

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?

It provides clear context for when to use this tool (creating a visual) and references sibling tools like pbi_list_visuals and pbi_get_visual for related tasks. However, it does not explicitly state when to use alternatives such as pbi_duplicate_visual or pbi_delete_visual, so exclusions are implied rather than explicit.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/HorizunGroup/horizun-pbi-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server