Horizun PBI MCP

Official

by HorizunGroup

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.2
Disambiguation2/5
Multiple tools have overlapping purposes: three HTML preview tools (pbi_export_page_html, pbi_preview_spec_html, pbi_preview_page_spec), several audit/diagnostic tools (pbi_audit_project, pbi_audit_model, pbi_diagnose_data, pbi_profile_data), and numerous page/visual creation tools (pbi_create_visual, pbi_create_page_from_spec, pbi_compose_page, pbi_build_dashboard). Despite detailed descriptions, an agent could easily select the wrong tool.
Naming Consistency4/5
The vast majority of tools follow the consistent pbi_verb_noun snake_case pattern (e.g., pbi_create_measure, pbi_list_tables, pbi_apply_theme). A few exceptions like pbi_start_here, pbi_capabilities, and pbi_health_check break the verb-object convention, but they are minor deviations.
Tool Count1/5
127 tools is an extreme count, far beyond the recommended 3-15 and even beyond the 25+ threshold for 'too many'. This places an enormous cognitive burden on an agent and makes the tool set unwieldy, despite the comprehensive coverage.
Completeness4/5
The tool set covers the full lifecycle of Power BI projects: model objects (tables, measures, columns, relationships), report pages and visuals, themes, bookmarks, plus auditing, validation, backups, and documentation. Minor gaps exist (e.g., no direct editing of Power Query M steps), but the surface is remarkably complete for the stated domain.
Average 4.1/5 across 127 of 127 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 169 commits in the last 12 weeks
- Last stable release on August 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations show readOnlyHint=false, but the description does not clarify what side effects building a page has (e.g., whether it creates a new page, overwrites an existing one, or requires specific model state). No behavioral traits beyond the annotation are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It lacks essential information about the tool's behavior and parameters, so the single sentence does not earn its place as an adequate description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a build tool with 6 parameters and no schema coverage, the description is severely incomplete. It does not explain what the page building entails, how parameters affect the output, or any dependencies, making it insufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 6 parameters, the description fails to explain any of them. It mentions 'fila de KPIs' and 'grafico protagonista' but does not connect these to the 'measures' or 'category' parameters, leaving the agent unable to infer parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Pagina de resumen ejecutivo: fila de KPIs y grafico protagonista' gives a vague idea that the tool produces an executive summary page with a KPI row and a featured chart, but it uses a noun phrase rather than a clear verb, so it doesn't explicitly state what the tool does. It implies building, but doesn't distinguish from sibling tools like pbi_build_dashboard or pbi_compose_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool compared to alternatives. No context, prerequisites, or exclusions are provided, leaving the agent without direction on selecting it over similar page-building tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, offering no safety or side-effect information. The description adds that the page must exist (implying an error for nonexistent pages) and specifies the output content (layout + fields), but it does not disclose whether the HTML is returned directly or written to a file, nor any potential 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 a single concise sentence, front-loaded with the verb and resource. Every word adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is sparse. It lacks details on return format, side effects, and parameter format. Given the tool's simplicity, the description is minimally viable but has clear gaps in usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify the 'page' parameter. It only indicates that the page must exist, but does not specify whether the parameter expects a page name, ID, or other identifier. This leaves ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports an HTML layout of an existing page, including layout and fields of each visual. This is specific enough to distinguish from sibling tools like pbi_list_visuals or pbi_get_visual, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. The description implies it is for exporting an HTML mockup of an existing page but does not mention exclusions or alternative tools such as pbi_preview_page_spec.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds a list of concrete quality checks, which provides useful context. However, it does not disclose additional behavioral traits such as how results are returned, model loading requirements, or performance implications.
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 concise and front-loaded: the first sentence summarizes the core purpose, and the second sentence is a compact list of checks. Every sentence earns its place with no redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return value details are not necessary. The description provides a solid list of checks, but it omits parameter semantics and usage context, and it does not clarify how this tool relates to similar audit/diagnostic siblings. Given the tool's complexity, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'source' has a default 'live' but no schema description, and the tool description does not mention or explain it. With 0% schema description coverage, the description fails to compensate or add any meaning to the parameter, leaving agents guessing about valid values or behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects typical model quality problems ('Detecta problemas tipicos del modelo (calidad)') and lists specific checks (measures without folder, long DAX, bidirectional/inactive relationships, calculated columns, visible IDs, missing calendar). This is a specific verb+resource and gives concrete scope, though it does not explicitly differentiate from overlapping siblings like pbi_audit_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. With many sibling tools for auditing (pbi_audit_model, pbi_health_check, pbi_diagnose_data), the description only states what it checks, not when to choose it over others or what prerequisites exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already provide. Annotations indicate readOnlyHint=false and destructiveHint=false, but the description does not disclose whether the operation is reversible, requires permissions, or how it affects the visual's existing layout. Since it's a mutation tool, more transparency would be expected.
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 a single, concise sentence that is front-loaded with the action. It contains no unnecessary words or repetition, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six required parameters and no parameter semantics in the description, the tool is under-specified. The description does not clarify coordinate systems, units, or how the visual is identified, making it incomplete for an agent to use correctly. The output schema exists but does not compensate for the lack of context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any of the eight parameters (x, y, width, height, page, visual_id, etc.), leaving the agent to infer their meaning from the schema alone. This is a significant gap for a tool with six required parameters.
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 'Mueve/redimensiona un visual existente' clearly states the tool moves/resizes an existing visual, which is a specific verb+resource action. It distinguishes from sibling tools like pbi_set_visual_z_order (z-order) and pbi_duplicate_visual (copy) by focusing solely on position/size.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for moving/resizing visuals but does not mention when to use it over alternatives like pbi_align_visuals or pbi_set_visual_z_order. There are no explicit exclusions or alternative references, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds that the tool returns hierarchies with 'niveles y columnas' (levels and columns), which is useful but minimal behavioral context beyond the annotation.
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 a single concise sentence that directly states the tool's function without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists and the read-only annotation covers safety, the description leaves the 'source' parameter unexplained. The description is adequate for the core purpose but incomplete for fully correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'source' is not described in the input schema, and the description does not mention it. With 0% schema coverage, the agent has no guidance on valid values or how to use this parameter.
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 clearly states the tool lists model hierarchies with their levels and columns, using a specific verb and resource. It distinguishes itself from sibling tools like pbi_list_tables or pbi_create_hierarchy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or context. It simply states what it does without comparing to sibling list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the deterministic property (same input yields same output), which is not in annotations. However, it does not disclose side effects, whether the operation modifies the report, or any permission requirements. Annotations are sparse but not contradicted.
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 very short and front-loaded with the main purpose in the first line. The additional notes on edge values and determinism are useful, but the brevity omits necessary parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 params, no enums, no effective annotations, and 0% schema coverage, this description is under-specified. It does not explain the relationship with sibling layout tools, what happens to visual positions, or any operational context like return values or error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters, but it only documents `edge` with valid values. `page`, `visual_ids`, and `request_id` are left unexplained, relying on inference from the tool name.
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 clearly states the tool aligns multiple visuals by an edge, listing specific edge options (left, right, top, bottom, center_h, center_v). This distinguishes it from sibling tools like distribute or arrange, which have different alignment logic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for edge-based alignment but provides no explicit guidance on when to choose this over pbi_arrange_visuals, pbi_distribute_visuals, or pbi_normalize_page_layout. No alternative tools are mentioned or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations are all false, so they provide no safety hints. The description adds important behavioral context by disclosing that the tool writes to TMDL and requires the project to be closed in Power BI Desktop. However, it does not disclose other behavioral traits such as whether overwriting is destructive or what side effects occur beyond the TMDL write.
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 concise and structured across three short sentences. The first sentence gives the purpose, and the subsequent sentences clarify key parameters and a critical prerequisite. It is not overly verbose, though it could benefit from clearer separation of parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no schema descriptions, no annotation hints), the description is incomplete. It covers the core purpose and two parameter semantics, plus a prerequisite, but does not explain the return value/output, the remaining parameters, or the broader model modification implications. This is insufficient for an agent to fully understand the tool's capabilities and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate. It explains two parameters (data_type and summarize_by) with meaningful detail, but there are 11 parameters total. It does not describe the required parameters table, name, and expression in detail, nor the optional ones like overwrite, is_hidden, format_string, and display_folder. This leaves many parameters without adequate semantic guidance.
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 clearly states the tool creates a calculated column (DAX) in a table of the .pbip model, using a specific verb and resource. It distinguishes from sibling tools like pbi_create_measure and pbi_create_calculated_table by specifying 'column' and the model context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention when to use this tool versus alternatives like pbi_create_measure or pbi_create_calculated_table. It does provide a key usage constraint—the project must be closed in Power BI Desktop—which gives some guidance on prerequisites, but lacks explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety hints (readOnlyHint=false, destructiveHint=false), so the description carries the burden. It usefully discloses that fields are validated and not invented, that the page gets cards and charts, and that a summary is returned. It does not mention side effects like overwriting pages or creating measures when create_missing_measures is true.
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 concise and front-loaded with the core purpose, followed by a short process list. Each sentence adds useful information, though the phrasing could be tightened slightly without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the return summary need not be over-explained. However, the description omits critical context about which parameters control the generation, prerequisites (e.g., selected model), and how this tool differs from similar page-creation siblings. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not mention any of the six parameters by name. Only 'layout indicado' loosely alludes to the layout parameter, and no guidance is given for page_name, objective, request_id, available_fields_hint, or create_missing_measures.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a report page with visuals proposed from the model, using specific verbs like 'Genera' and 'crea'. It outlines key actions (validating fields, adding cards and charts) but does not explicitly distinguish itself from sibling tools like pbi_compose_page or pbi_create_page_from_spec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an AI-generated page layout from the model is desired, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. The step-by-step process gives some context, but no exclusions or comparison to related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by explaining the exact content of the return payload, including the 'definicion cruda' for deeper inspection needs. This adds meaningful context about what the tool discloses and its completeness. It does not contradict the annotations and adds value beyond the simple read-only marker.
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 two sentences long, front-loaded with the core purpose, and every word earns its place. It efficiently enumerates the returned fields without unnecessary elaboration. This is an exemplary model of concise, informative tool documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so the return value list is redundant but helpful. However, the complete lack of parameter semantics and usage guidance leaves the description incomplete for an agent trying to invoke it correctly. For a simple read-only getter, it is adequate but has clear gaps in parameter and alternative guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for the two parameters (page, visual_id), and the description provides no explanation of their meaning, format, or constraints. This is a significant gap since the schema itself offers no help. The parameter names are somewhat self-explanatory, but the description does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a complete and normalized definition of a visual, listing specific attributes (type, position, Z-order, title, fields, filters, raw definition). This distinguishes it from list-oriented siblings like pbi_list_visuals, though it does not explicitly name an alternative. The verb 'Devuelve' (returns) indicates the retrieval action, but it is slightly less direct than a verb-first description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a full, normalized visual definition is needed, including raw inspection data. However, it provides no explicit guidance on when to use this tool versus alternatives such as pbi_get_object or pbi_list_visuals, nor any exclusions. The context is clear but not fully developed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds useful context about the output content (tables/columns, cardinality, cross-filter, status), which helps set expectations. However, it doesn't disclose behavior regarding the 'source' parameter or potential limitations.
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 a single concise sentence that front-loads the main action and lists the key output aspects without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values are covered. The description adequately covers the main functionality but leaves the 'source' parameter unexplained and doesn't position the tool within the broader model inspection workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description completely ignores the single 'source' parameter. With 0% schema description coverage and no explanation in the description, the agent has no information about this parameter's purpose, allowed values, or effect on results.
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 clearly states the tool lists relationships and specifies the key attributes included (tables/columns, cardinality, cross-filter, status). This directly differentiates it from sibling list tools like pbi_list_tables and pbi_list_measures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The name implies the purpose, but the description lacks explicit context, prerequisites, or comparisons to other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety hints (all false), so the description carries the burden. It discloses a default behavior (visual_ids defaults to all) and the structure of custom positioning, but it does not mention reversibility, side effects, or required permissions. This is partial transparency for a mutation tool.
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 highly concise: two sentences plus a compact parameter reference. It front-loads the main action and uses a clear, structured format for parameter details. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys the core action and main parameters, but it does not explain the meaning of 'dashboard' or 'executive_summary' layouts, the 'canvas' and 'spacing' parameters, or potential side effects. Since the output schema exists, return values need not be described, but the missing parameter context leaves the description partially incomplete for a 7-parameter mutation tool.
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?
The description adds valuable semantics for 'layout' (enumerating grid, dashboard, executive_summary, custom) and 'visual_ids' (optional subset, defaults to all) and 'custom' (map format). However, with 7 parameters and schema coverage at 0%, it fails to explain 'page', 'canvas', 'spacing', and 'request_id', leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Reorganiza los visuales de una pagina' (reorganizes the visuals of a page). It specifies the resource (visuals on a page) and the action (reorganize), and lists layout options. However, it does not explicitly differentiate from sibling tools like pbi_align_visuals or pbi_distribute_visuals, so it misses full distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining layout options and the optional visual_ids subset, but it provides no explicit guidance on when to use this tool versus alternatives (e.g., align, distribute, normalize). There are no stated prerequisites or exclusions, so guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds conceptual context about design systems (color/typography palettes, canvas size, grid, text scale) and the consequence of changing systems late. This adds value beyond the annotation but does not disclose concrete behaviors like return format or pagination. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet informative. It front-loads the core purpose in the first sentence, then provides a helpful conceptual explanation. The metaphor about a room board versus a PDF is illustrative but slightly extraneous; still, it reinforces the importance of choosing early. Every sentence contributes meaning, and the length is appropriate.
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 a simple list tool with an output schema, the description provides sufficient context: it explains what design systems are, what they include, and why they should be chosen before building pages. It does not explicitly link to pbi_apply_design_system, but the overall guidance is complete enough for an agent to understand the tool's role in the workflow.
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?
The only parameter is 'request_id', an optional string with a default of ''. The description does not discuss parameters, and schema description coverage is 0%. However, the parameter is trivial and self-explanatory from the schema. The description adds no parameter meaning, but none is really needed for such a simple optional field, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins 'Sistemas de diseno disponibles: para que sirve cada uno y que trae' which clearly indicates this is a listing tool for design systems, and goes on to explain what a design system encompasses (theme, canvas, grid, text scale). The name also clearly states the verb 'list' and resource 'design systems'. It somewhat distinguishes from sibling pbi_list_themes by describing the broader scope of design systems, though not explicitly naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives important timing guidance: 'Eligelo ANTES de la primera pagina; cambiarlo despues obliga a recolocarlo todo.' This implies when to use this tool (before starting page composition) and why it matters. However, it does not explicitly contrast this tool with related siblings like pbi_apply_design_system or pbi_list_themes, nor does it 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations all false and unhelpful, the description carries the burden of behavioral disclosure. It clearly states the tool does not write to the .pbip and that the preview accurately reflects the final compiled output, which is valuable transparency about side effects and reliability.
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 very concise, with the main purpose front-loaded in the first sentence. The second sentence adds essential accuracy details without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's purpose and output fidelity, and the presence of an output schema reduces the need to describe return values. However, the complete lack of input parameter explanation and no explicit contrast with the very similar sibling tool pbi_preview_spec_html leave meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the 'spec' or 'seed' parameters. Since the schema provides no descriptions, the description needed to compensate but did not address parameter semantics at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an HTML mockup of the spec with final positions and explicitly notes it does not write to the .pbip file. This distinguishes it from apply/write tools, though it does not explicitly differentiate from the similar sibling pbi_preview_spec_html.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is meant for previewing exactly what will be written before committing, which gives contextual usage guidance. However, it does not explicitly state when to use this tool over alternatives like pbi_preview_spec_html or pbi_validate_page_spec.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds that backups are timestamped and returns the path. It does not disclose where backups are stored, whether they overwrite, or if an active project must be open, leaving gaps for a mutation tool.
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?
Two sentences: first states purpose, second lists options and return value. Front-loaded, no fluff, and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema likely covers the return path, and the core action is clear. However, missing context about backup location, project prerequisites, and interaction between mode and scope reduces completeness for safe and effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It merely lists mode values (folder|zip) and scope values (report|model|both) without defining them, and request_id is completely undocumented. This is insufficient for correct parameter use.
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 clearly states the tool's purpose: creates a timestamped backup of the active .pbip project. It uses a specific verb ('Crea') and resource, distinguishing it from sibling tools like pbi_convert_pbix_to_pbip or pbi_purge_backups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (backing up a project) but does not explicitly state when to use it or mention alternatives. It gives no 'when not to use' guidance, though the self-explanatory backup context provides some implicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations set to false, the description carries the burden of behavioral disclosure. It reveals that the operation writes TMDL, requires a closed project, and deliberately preserves the order of levels without sorting or deduplication. Missing overwrite behavior and error handling, but the disclosed traits are meaningful and non-obvious.
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 compact and front-loaded: a purpose sentence, a focused parameter note, and a prerequisite. It has no wasted sentences, though the phrase 'porque es informacion' is slightly awkward and could be tightened. Overall, it is concise and well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description captures the core invocation requirements: same-table columns, correct level order, and a closed Power BI project. However, with seven parameters and zero schema descriptions, it leaves overwrite semantics and optional fields under-specified. An output schema exists but does not compensate for these parameter knowledge gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It does this only for `levels`, which is richly explained with ordering and preservation semantics. The remaining six parameters—`table`, `name`, `overwrite`, `request_id`, `description`, and `display_folder`—are left to name-based inference, which is insufficient at this coverage level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Crea una jerarquia sobre columnas de la misma tabla', which clearly identifies the verb (create) and resource (hierarchy on columns of a table). It does not explicitly distinguish itself from sibling creation tools, but the hierarchy object type is unambiguous enough to avoid confusion with measure or column creation.
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 gives a concrete prerequisite: 'requiere el proyecto CERRADO en Power BI Desktop' and specifies the required ordering of levels from high to low granularity. It does not mention when to choose an alternative tool, but the closed-project requirement and ordering semantics are useful usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the burden of disclosing side effects. It explicitly states 'Guarda el archivo en outputs/' (saves the file in outputs/), which is a useful side-effect disclosure beyond annotations. However, it does not mention whether existing files are overwritten or if a live connection is required.
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 two sentences long, front-loaded with the main action, and lists included content and output location without unnecessary detail. Every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values are handled. The description covers the core purpose and side effect, but lacks parameter semantics and explicit usage guidance. For a tool with two parameters and a file output, it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides almost no parameter information. It mentions quality warnings, which weakly hints at 'include_quality', but completely ignores the 'source' parameter. The description fails to compensate for the lack of schema documentation.
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 clearly states the tool generates complete model documentation in Markdown and lists the specific included components (summary, tables, columns, measures, relationships, hierarchies, roles, quality warnings). This distinguishes it from sibling tools like pbi_model_summary or pbi_audit_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when full model documentation is needed, but does not explicitly state when to use this tool versus alternatives. There are no exclusions or comparisons to sibling tools like pbi_generate_technical_documentation or pbi_model_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only behavior (readOnlyHint: true), and the description adds meaningful detail beyond that: it explains that measures include DAX references and that columns require a specific bracket syntax. This goes beyond the basic safety profile and clarifies the output contents.
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 compact and front-loaded, with the core purpose in the first sentence. The subsequent two sentences deliver specific, non-redundant usage details. Every sentence earns its place, achieving high information density without clutter.
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?
Given the output schema exists (avoiding the need to detail return values) and the read-only annotation covers safety, the description is largely complete for the tool's complexity. It explains the main parameters and a special behavior (measure DAX references). The only gap is the undocumented 'source' parameter, but overall it offers enough context for correct invocation.
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 compensates by explaining the 'kind' values (table/column/measure) and the naming format for columns. However, the 'source' parameter is left completely unexplained, and 'name' semantics are only partially implied through the column example. It adds value but does not fully replicate missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Devuelve un objeto del modelo con todo su detalle' (returns a model object with all its detail). It also enumerates the supported kinds (table, column, measure), which further clarifies the scope. However, it does not explicitly differentiate this tool from sibling getters like pbi_get_visual or pbi_measure_dependencies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific naming convention for columns ('Tabla[Columna]') but offers no when-to-use guidance or exclusions relative to alternatives. There is no mention of when to prefer this tool over sibling tools, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the safety profile is known. The description adds that the results are organized by table and include storage mode and origin, which is useful but not extensive. No behavioral traits like requiring a selected model or response structure are disclosed, but the annotation covers the most critical aspect (read-only).
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 a single, concise sentence that directly states the tool's purpose. It contains no filler or repetition, and all words contribute meaning. This is an example of efficient writing without being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-only list operation with one optional parameter and an output schema. The description covers the core function but leaves the 'source' parameter unexplained, which is a completeness gap. Given the low complexity, the description is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter 'source' with a default value but no description, and schema_description_coverage is 0%. The description does not mention or explain the 'source' parameter at all, leaving its meaning and accepted values ambiguous. This is a significant gap since the description must compensate for the schema's lack of detail.
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 clearly states the tool lists partitions grouped by table, including storage mode and origin. The verb 'list' and resource 'partitions' are specific, and the detail 'by table (storage mode and origin)' distinguishes it from sibling tools like pbi_list_tables or pbi_set_storage_mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to see partitions with their storage mode and origin. However, it does not explicitly state when to prefer this tool over alternatives, nor does it mention exclusions or prerequisites. The implied context provides some guidance but lacks explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds a minor behavioral detail—filters are grouped by table ('por tabla')—but it does not disclose output format, pagination, or any other behavioral traits. This is slightly more than nothing, but still limited.
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 a single, front-loaded sentence in Spanish that directly states the tool's purpose. Every word earns its place, with no filler or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, read-only, and has an output schema, so the description doesn't need to explain return values. However, the 'source' parameter is left undocumented, and there is no explicit context about when this tool is the right choice among the many sibling tools. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter ('source') with a default value, but schema description coverage is 0%. The description does not mention or explain the 'source' parameter at all, leaving the agent to guess what values are valid or how it affects the result. This is a clear gap.
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 uses a specific verb ('Lista') and a specific resource ('roles de seguridad (RLS)') and adds the scope 'sus filtros por tabla', clearly distinguishing it from other list tools like pbi_list_tables or pbi_list_measures. It leaves no doubt about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in security-role contexts, but it does not explicitly state when to use this tool versus alternatives such as pbi_list_audit_rules or other listing tools. There are no exclusions or alternative recommendations, so usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it warns that changing to 'single' can alter totals, and it explains the 'mode' parameter's behavior with 'live' vs 'pbip' and the temporary disabling of 'mode='both''. This goes beyond the basic readOnlyHint/destructiveHint flags, which are all false, and provides useful side-effect information.
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 concise and front-loaded with the tool's purpose. It then provides essential parameter details and warnings in a readable format. The 'OJO' and 'No confundir' notes are useful and not overly verbose. It could be slightly more structured, but it is well within acceptable length.
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?
Given that an output schema exists, the description need not explain return values. It covers the tool's purpose, key parameter semantics, and important behavioral caveats (side effects on totals, mode restrictions). While it doesn't discuss prerequisites like model selection or relationship identification, the core operation is well-described for a tool of this complexity.
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?
With 0% schema description coverage, the description compensates for the most critical parameters. It explains the meaning and allowed values for 'direction' ('single' vs 'both') and clarifies the confusing relationship between 'direction' and 'mode', including the caveat about 'mode='both''. However, it does not explain 'from_table', 'to_table', or 'request_id', though these are somewhat self-explanatory from their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Cambia el filtro cruzado de una relacion' (changes the cross-filter direction of a relationship). This is a specific verb and resource, effectively distinguishing it from sibling tools like pbi_create_relationship or pbi_list_relationships, though no explicit sibling differentiation is mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It only implies usage through the purpose statement and gives parameter-level warnings (e.g., about 'mode'), but there is no clear context about prerequisites, alternative tools, or situations where this tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that each finding includes specific fields and that evidence always accompanies findings, meaning heuristics are not presented as certainty. This goes beyond the readOnlyHint annotation by explaining the epistemic behavior of results.
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?
Three sentences cover purpose, output shape, and core parameters with no filler. Front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema is present and the description covers the main result structure, but the `source` parameter is unexplained and no sibling differentiation is given. For a 3-parameter tool with zero schema descriptions, this leaves some ambiguity.
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?
The description explains the meaning of `rules` and `min_severity`, including the accepted values for min_severity. The `source` parameter is left undocumented, and with 0% schema coverage, this is a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Audita el modelo semantico' with a specific verb and resource, clearly identifying the tool's function. However, it does not differentiate from sibling audit tools like pbi_audit_project or pbi_audit_report_only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description references pbi_list_audit_rules for the rules parameter, providing a path to discover valid rules. It does not state when to use this over pbi_audit_project or pbi_audit_report_only, so usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no meaningful behavioral hints (all false), so the description must carry the burden. It usefully discloses that the tool validates measures and will warn instead of generating a nonsense page. However, it does not mention the behavior of the dry_run parameter, whether the tool modifies an existing report/page, or other side effects, leaving gaps.
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 two short sentences in Spanish, front-loaded with the page type and immediately followed by key validation behavior. Every sentence adds value and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has 6 parameters with no schema descriptions and no explanation of prerequisites or how parameters like `dry_run`, `seed`, or `category` affect the result. The description covers only the `measures` parameter and validation behavior, which is not enough for reliable invocation in a large sibling-tool context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for 6 undocumented parameters. It clarifies the `measures` parameter by listing expected types, but it leaves `name`, `seed`, `dry_run`, `category`, and `request_id` completely unexplained. This is insufficient for an agent to correctly set all parameters, especially the critical `dry_run` flag.
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 clearly identifies the tool as generating an EVM page and specifies the expected measure types (PV, EV, AC, CPI, SPI). The phrase 'generar una página' explicitly states the action, and the EVM-specific scope distinguishes it from sibling tools like pbi_build_executive_page.
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 gives clear context for use: it should be used when EVM measures are present, and it warns if it cannot recognize them rather than producing a meaningless page. It does not name alternative tools or explicitly state when not to use it, but the usage context is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond annotations: it clones existing visuals as templates, makes a backup, and auto-arranges visuals when 'position' is omitted. However, it does not disclose what happens if the page already exists or how existing content is affected, leaving some ambiguity.
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 compact and well-structured, with the main purpose in the first sentence and a clear code block for the spec schema. Every sentence adds value, and there is no redundant or vague content.
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?
Given the nested spec object and zero schema coverage, the description covers most necessary aspects: spec structure, cloning, backup, and layout behavior. It falls short only in explaining the 'rol:refs' field notation and how this tool relates to sibling spec-validation/preview tools, but it remains quite complete for its complexity.
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?
The schema is opaque for the 'spec' object (additionalProperties true, 0% description coverage), but the description fully documents its internal structure: page_name, canvas, layout enum, and visuals with type/title/fields/position. It also explains the behavioral meaning of omitting 'position', which is essential for correct use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a complete PBIR page from a spec, using a specific verb and resource. It distinguishes itself by mentioning spec-driven creation and cloning existing visuals, but it does not explicitly differentiate from sibling tools like pbi_apply_page_spec or pbi_compose_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as pbi_apply_page_spec or pbi_generate_report_page. It only describes the spec format without any exclusions, prerequisites, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations are all false (readOnlyHint=false, destructiveHint=false, etc.), providing no safety or side-effect hints. The description only says it generates Markdown documentation but does not clarify whether this is a read-only operation, whether it writes files, or if it requires a specific report context. This lack of transparency is a significant gap.
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 a single, concise sentence that is front-loaded with the action and object. It includes the output format (Markdown) and scope (pages and visuals) without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is an output schema (as indicated by context signals), so return value details are covered. However, the description lacks context about prerequisites (e.g., whether a report must be open) and the expected output structure. For a simple tool with no parameters, this is a moderate gap.
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?
The tool has zero parameters, so the schema is empty. The description adds no parameter details, but this is acceptable because there are no parameters to explain. The baseline of 4 for zero-parameter tools applies.
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 clearly states a specific action ('Genera documentacion Markdown') and a specific resource ('del layout del informe (paginas y visuales)'). This distinguishes it from sibling tools like pbi_document_model, which focuses on the data model, and pbi_generate_technical_documentation, which covers broader documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when report layout documentation is needed, but it does not explicitly state when to use this tool over alternatives or provide exclusion criteria. There is no mention of prerequisites or alternatives, making the guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which are all false), the description discloses that the report's publicCustomVisuals are modified and that Power BI Desktop downloads the visual from AppSource when opening the report. This adds useful behavioral context, though it does not mention permissions or network requirements.
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 two sentences: the first states the core action and target, the second covers the default behavior and download-side effect. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no required parameters and an output schema, so basic invocation is covered, but the missing parameter semantics and lack of alternative-tool guidance leave gaps. It is adequate for the simple no-argument use case but not fully complete for selecting other AppSource visuals.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description carries the full burden but only explains the no-argument case. It does not explain what visual_id values are expected or the purpose of request_id, leaving the agent guessing about both parameters.
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 'Registra un custom visual de AppSource en el informe (publicCustomVisuals)', a specific verb plus the resource (AppSource custom visual) and target (report). It also clarifies the no-argument default to 'HTML Content', distinguishing it from generic visual creation tools like pbi_create_visual or pbi_add_image_resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating that without arguments it registers 'HTML Content', which tells the agent when no visual_id is needed. However, it does not explicitly state when to use this tool over siblings such as pbi_create_visual or pbi_create_html_visual, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotations: destructiveHint=false, yet sync_mode=replace 'ademas elimina los visuales ausentes' (deletes absent visuals). This is a direct conflict, forcing a score of 1 per the contradiction rule, despite otherwise rich disclosure of outcomes, id preservation, and dry_run semantics.
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 well-structured and front-loaded: core purpose first, then outcomes, then per-parameter explanations. Each sentence adds necessary information; the formatting with backticks and line breaks improves readability without bloat.
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 a complex tool, the description covers outcomes, parameter behaviors, interaction referencing/types, and dry_run. It omits seed and request_id, and the spec object's schema is not detailed, but the presence of an output schema reduces the burden for return-value explanations. Overall strong, with minor gaps.
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?
With schema description coverage at 0%, the description compensates by explaining page (id/name, defaults), sync_mode (merge vs replace, conservative default), interactions (referencing by position/id/title, types), and dry_run (plan_token, no write). However, seed and request_id are not mentioned, and spec's full structure is only partially addressed.
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: 'Materializa el spec como una pagina PBIR, en UNA transaccion.' It clearly distinguishes the tool's role as the writer (apply) versus preview/validate siblings, and enumerates four explicit outcomes (create, update, no_change, conflict).
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 gives clear context: it applies a page spec transactionally, with dry_run as a safe planning mode, and explicitly mentions pbi_apply_plan as a follow-up. It does not explicitly exclude alternatives or state when not to use, but the usage context is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It adds a behavioral detail beyond annotations: the minimum number of visuals required for the operation to have effect. Annotations only indicate non-read-only and non-destructive, so this context is useful. It doesn't disclose side effects or error conditions, but the main behavior is covered.
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 highly concise: two short sentences with the main verb front-loaded. It includes essential details without any fluff, making it easy to scan and understand.
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?
Given the tool's simplicity and the presence of an output schema, the description is fairly complete. It explains the core action, axis parameter, and a critical constraint. It doesn't explain every parameter, but those are self-explanatory from names and schema defaults.
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?
Schema description coverage is 0%, and the description partially compensates by explaining the `axis` parameter with 'horizontal|vertical'. It does not elaborate on `page`, `visual_ids`, or `request_id`, but those are somewhat inferable from names. The added axis semantics are helpful but incomplete.
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 clearly states the tool's function: 'Reparte visuales con separacion uniforme' (distributes visuals with uniform separation). This specific verb+resource combination distinguishes it from sibling tools like pbi_align_visuals and pbi_arrange_visuals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a key usage precondition: 'Necesita al menos tres visuales' (needs at least three visuals), explaining behavior with two visuals. However, it does not explicitly mention when to prefer this tool over alternatives, relying on the purpose to imply usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior beyond the annotations: it explains that duplication is atomic ('in a single transaction'), that unique identifiers (page and visual) are regenerated, and that everything else is preserved. This addresses side-effect expectations despite the annotations being mostly false/neutral.
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 concise: two sentences, front-loaded with the primary purpose and followed by key behavioral details. Every sentence adds value without unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core duplication behavior and ID regeneration, and an output schema exists to describe return values. However, it omits important operational constraints such as whether the source page must exist, whether 'new_name' must be unique, or what happens to visual references. This is adequate but incomplete for smooth invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'page', 'new_name', or 'request_id' parameters. It only indirectly references the page concept; 'new_name' and 'request_id' are left entirely unexplained, so the agent cannot infer parameter meaning from the description.
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 states a specific action ('Duplicates a page with all its visuals') and resource ('page'), clearly distinguishing it from sibling tools like pbi_duplicate_visual. It also adds scope ('all its visuals') and execution context ('in a single transaction').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use this when you need to duplicate a page and its visuals. However, there is no explicit guidance on when not to use it or which alternative to choose (e.g., pbi_duplicate_visual for just one visual, pbi_create_page_from_spec for building from spec).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a safe read operation. The description adds minimal behavioral context by clarifying that it returns the rules and their details, but does not disclose any additional traits such as permissions or data scope.
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 a single, clear sentence with no unnecessary words. It efficiently conveys the tool's purpose and output content.
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 a simple list tool with no parameters and an output schema present, the description is adequate. It specifies the resource (autofix rules) and the kind of information returned (what each rule consists of), which is sufficient for basic understanding.
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?
The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline of 4 is appropriate since the schema is empty and there is nothing to elaborate.
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 clearly states that the tool lists rules with automatic correction and describes what each rule consists of. It distinguishes itself from sibling tools like pbi_list_audit_rules by focusing specifically on autofix rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives or any conditions for its use. The description simply states what it returns, leaving the agent to infer usage from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context by enumerating the output fields (id, tipo, posicion, campos, titulo), which goes beyond the readOnlyHint annotation. However, it does not disclose behavior for edge cases such as empty pages or invalid page identifiers, and it relies heavily on the annotation for safety profile.
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 extremely concise, using only two sentences to convey purpose and parameter information. Every word earns its place, with no redundancy or filler.
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?
Given the tool's simplicity (one parameter, read-only listing) and the presence of an output schema, the description covers the essential aspects: what it does, what it returns, and the parameter meaning. It is complete enough for an agent to invoke it correctly, though it could mention error conditions or preconditions like the page existing in the current report.
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?
The input schema provides no description for the 'page' parameter, but the tool description compensates by explaining that it accepts an internal id or visible name. This adds meaning beyond the bare schema definition, making the parameter clear enough for 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 clearly states it lists the visuals of a page and specifies the returned fields (id, tipo, posicion, campos, titulo). This distinguishes it from sibling tools like pbi_get_visual (which retrieves a single visual) and pbi_list_report_pages (which lists pages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives like pbi_get_visual or pbi_list_report_pages. It only states the basic function and parameter, leaving the agent to infer appropriate usage without explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the detail that it uses a 'trivial query,' implying lightweight behavior, but does not disclose what happens on failure, output specifics, or any side effects beyond the annotation. 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?
A single, front-loaded sentence with no filler. It efficiently communicates the tool's purpose and method, earning a perfect score for conciseness.
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?
Given the tool's simplicity (zero params, output schema present, read-only annotation), the description is largely sufficient. It clearly states the tool's function. The only gap is the lack of usage context, but this is covered under the usage_guidelines dimension and does not heavily penalize completeness for such a trivial tool.
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?
The tool has zero parameters, so the schema is fully covered (100%). The baseline for 0 params is 4, and the description does not need to add parameter details. It correctly focuses on the operation itself.
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 clearly states a specific action (validates) on a specific resource (connection to the active model) using a specific method (trivial query). It distinguishes itself from broader tools like pbi_health_check by focusing on the active model connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios like 'before running other operations' or contrast with pbi_health_check or pbi_session_info, which likely have overlapping purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (no readOnly/opensWorld hints), so the description carries the full burden. It discloses that the tool writes to TMDL ('Escribe en TMDL'), requires the project closed, and explains the ambiguity implications of cross-filtering directions. This adds valuable behavioral context beyond the schema, such as the default safe behavior and the need to justify complex filtering scenarios. It does not discuss side effects like overwriting (though an 'overwrite' parameter exists), but the key behavioral traits are covered.
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 three concise sentences, each adding distinct value: purpose, default behavior/guidance, and a key requirement. It is front-loaded with the action and avoids filler or repetition. No word is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool is complex (11 parameters, mutating operation, TMDL writing). The description covers the default cardinality and cross-filtering warning, plus the closed-project prerequisite, but leaves most parameters unexplained and does not describe return values or error scenarios. Given the zero schema coverage, this is not complete enough for an agent to confidently invoke the tool with correct parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for all 11 parameters. The description only adds semantics for 'cross_filtering' (explains the default 'oneDirection' and warns about 'bothDirections') and implicitly for cardinalities (default many-to-one). It does not explain 'from_table', 'to_column', 'is_active', 'overwrite', 'name', 'request_id', or other parameters. This is insufficient for a tool with 11 parameters and zero schema-level documentation.
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 clearly states the tool's action: 'Crea una relacion entre dos columnas del modelo .pbip' (creates a relationship between two columns). This specific verb+resource combination distinguishes it from siblings like pbi_set_relationship_direction (which changes direction) and pbi_list_relationships (which lists relationships). The scope (.pbip model) is also explicit.
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 provides explicit guidance on default cardinality and filtering ('muchos-a-uno con filtro en un sentido... lo unico que no introduce ambiguedad') and warns against using 'bothDirections' unless justified. It also states a critical prerequisite: the project must be CLOSED in Power BI Desktop when writing TMDL. However, it does not explicitly name sibling alternatives, so it lacks a direct when-to-use vs. alternative comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
La descripción añade información valiosa más allá de las anotaciones neutrales: revela que solo se regenera el identificador (que debe ser único), que la copia se desplaza con offset_x/offset_y para no superponerse, y que target_page permite copiar a otra página. Esto cubre efectos clave de la operación, aunque no detalla permisos ni reversibilidad.
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?
La descripción consta de tres oraciones breves y directas, con la información principal al inicio. No hay relleno ni repetición de lo que ya está en el schema; cada oración aporta un dato relevante.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
La herramienta tiene 7 parámetros y es mutadora, pero la descripción cubre el comportamiento central y la existencia de output schema evita explicar retornos. No obstante, la falta de explicación para request_id y matices de new_title deja lagunas para una invocación correcta. En general es útil pero no completa.
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?
La cobertura del schema es 0%, por lo que la descripción debe compensar. Explica offset_x, offset_y y target_page con su propósito. Sin embargo, no aclara request_id, y el papel de new_title solo se infiere por el nombre. De los 7 parámetros, 3 reciben descripción semántica explícita, dejando vacíos para los demás.
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?
La descripción comienza con 'Duplica un visual conservando campos, formato y filtros', que es un verbo específico con recurso y alcance claro. Distingue de herramientas hermanas como pbi_create_visual o pbi_copy_visual_format al especificar qué se conserva y qué se regenera.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
El uso se implica claramente: duplicar un visual manteniendo propiedades. Sin embargo, no se mencionan cuándo no usar esta herramienta ni alternativas explícitas (por ejemplo, pbi_copy_visual_format o pbi_duplicate_page). Falta orientación contextual sobre escenarios o exclusiones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true, the safety profile is already covered. The description adds useful behavior beyond annotations: the output is an editable draft requiring review and validation, and it enumerates the allowed preset values. This helps set expectations without contradicting the read-only annotation.
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 compact and well-formatted, with a clear first sentence, a backtick-delimited parameter list, and a concise use instruction. Every sentence adds value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a clear workflow (generate, review, validate) and references an output schema, but it misses the required page_name parameter and does not mention defaults or constraints. Given the tool's moderate complexity and output schema presence, the description is adequate but not complete.
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?
Schema coverage is 0%, so the description carries the burden. It explains preset, measures, and category, but omits the required page_name parameter and the width/height parameters. This partial compensation is better than nothing but leaves critical parameters undocumented.
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 clearly states the tool 'Genera un borrador de spec' (generates a draft spec) from a preset and fields, with a specific verb and resource. It also distinguishes itself from sibling tools by mentioning the subsequent validation step with pbi_validate_page_spec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as the generation step by noting the result should be reviewed and passed to pbi_validate_page_spec, but it does not explicitly state when to use this tool versus alternatives like pbi_preview_page_spec or pbi_apply_page_spec. It provides a workflow hint but no exclusions or alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations do not convey any safety or behavior hints, so the description carries the burden. It discloses that the tool does not invent graphics when no captures are provided, reopens the PDF with pypdf, and renders the first page to PNG if Poppler is available, plus states the output directory. This adds meaningful behavioral context beyond 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 four sentences, each contributing useful information: main purpose, input constraints, behavior when captures are absent, and output details. It is dense but not bloated, appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 optional parameters and an output schema, the description gives enough to understand the core workflow and output location, but it does not explain several parameters or their interplay. The output schema covers return values, yet the lack of parameter descriptions makes the tool less than fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only elaborates on `capture_paths` (accepted formats, max 20, example source) and indirectly hints at `report_type` via 'executive, technical, or audit' and `include_audit` via 'audit information.' The remaining parameters (`title`, `source`, `file_name`, `max_findings`) are left unexplained, leaving a significant gap.
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 clearly states the tool 'generates an executive, technical, or audit PDF with captures' and explains it composes existing model, page, visual, and audit information. It distinguishes itself from siblings like `pbi_generate_technical_documentation` by focusing on PDF generation with screenshots and references `pbi_validate_desktop_render` for input paths.
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 provides clear context by specifying that `capture_paths` should contain paths returned by `pbi_validate_desktop_render`, implying use after rendering desktop captures. It does not explicitly mention when not to use or name alternative tools, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses important behavioral constraints: 'live' requires Power BI Desktop open, 'pbip' requires it closed, and mode='both' is disabled. This explains why only one destination can be applied per call and clarifies the default mode's prerequisite.
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 a single paragraph of about 80 words, front-loaded with the purpose statement. It covers essential mode behavior and prerequisites without redundancy, though it could be structured more clearly.
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?
The tool's mode complexity is thoroughly addressed: the disabled 'both' option, prerequisites for 'live' and 'pbip', and 'auto' behavior are all explained. With an output schema present, return-value documentation is unnecessary, but request_id remains unexplained.
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 compensates for the 'mode' parameter by explaining its values and default behavior. However, it leaves 'table', 'column', 'hidden', and 'request_id' without additional semantics, though most are self-explanatory from names/types.
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 states 'Oculta o muestra una columna del modelo', which is a specific action (hide/show) on a model column. It implicitly differentiates from the sibling tool pbi_hide_columns by including 'muestra' (show) and singular 'columna', making its scope clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed guidance on mode selection ('live' vs 'pbip' vs 'auto') and warns that 'both' is temporarily disabled due to conflicting prerequisites. However, it does not explain when to choose this tool over alternatives like pbi_hide_columns, so tool-selection guidance is implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only action, and the description adds valuable behavioral details: the file is copied to StaticResources, report.json is modified, and a missing declaration causes a blank visual with no error. It also explains the return value. This goes beyond the structured metadata and enhances transparency.
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 concise and well-structured: it front-loads the purpose, explains the mechanism and failure mode, then describes the return value and the only parameter it documents. Every sentence contributes essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, the critical mechanism, the failure mode, and the return value, making it usable for the primary workflow. However, given that schema coverage is 0%, the lack of explanation for `name`, `overwrite`, and `request_id` is a notable gap. The tool is simple enough to be used despite this, but completeness is only average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage), so the description must compensate. It only explicitly documents `path` (with allowed extensions .png .jpg .gif .bmp .svg). It indirectly mentions the return `item_name`, which may relate to `name`, but `name`, `overwrite`, and `request_id` remain unexplained, leaving ambiguity for the agent.
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 clearly states the tool's purpose: 'Incrusta una imagen en el informe' (embeds an image in the report). It specifies the exact mechanism (copy to StaticResources, declare in report.json) and the return value (item_name), making it distinct from sibling tools like pbi_add_custom_visual. This is a specific verb+resource+outcome, not a tautology.
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 provides clear context for when to use the tool: when you need to embed an image resource into a Power BI report. It also warns about the silent failure if both steps are not performed, which is helpful. However, it does not explicitly mention alternatives or when-not-to-use, but the purpose is narrow enough that this is not a major gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that when `formats` is specified, it 'escribe tambien esos informes en outputs/ y devuelve sus rutas', which is a clear side effect beyond what annotations indicate. It also reveals that it returns prioritized findings and auto-correction rule information, adding useful behavioral context. Annotations are all false and there is no contradiction.
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 three sentences long, each serving a distinct purpose: scope, outputs, and parameter behavior. It is front-loaded with the core purpose and contains no redundant or filler content. Every word earns its place.
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?
The description conveys the core inputs, the main outputs, and side effects (file writing), which is sufficient for an audit tool. The presence of an output schema (not shown) likely covers return details. It lacks explicit prerequisites (e.g., needing an open project or connection), but the surrounding context of sibling tools helps fill that 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 names all three parameters and gives a role for each: `formats` is shown with valid values and its side effect of writing reports; `rules` and `min_severity` are noted as 'acotan' (filter). However, it does not explain what `rules` contains or what severity levels are available, leaving some semantic gap.
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 'Auditoria integral: modelo semantico + informe + layout' which clearly defines a comprehensive audit covering all three areas. It enumerates specific outputs such as global/per-domain scores, executive summary, prioritized findings with evidence, and auto-correction rules, which makes the tool's purpose unambiguous. This integral scope distinguishes it from siblings like pbi_audit_report_only and pbi_audit_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies full coverage with 'Auditoria integral' but does not explicitly state when to use this tool over alternatives. No exclusions or comparisons to related tools (e.g., pbi_audit_report_only) are provided. The usage context is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description outlines the multi-step process (analyze, compose spec, calculate layout, preview, apply transaction, verify) and explains the dry_run default behavior. Annotations are all false and add little, so the description carries the burden and does so effectively, though it could detail failure handling or what 'applies' entials.
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 extremely concise: three sentences with a clear opening purpose, a workflow overview, and a critical default behavior note. Every sentence earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-step dashboard building), the description provides a high-level workflow but omits what 'objetivo' maps to in parameters, preconditions, or expected output. The presence of an output schema mitigates the need for return value details, but more guidance on how to phrase the objective would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly explains dry_run and references preset, but leaves name, measures, seed, category, and request_id undefined. The phrase 'desde un objetivo' vaguely implies name/measures define the goal, but this is not concrete enough for reliable parameter understanding.
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 clearly states it builds a complete dashboard from an objective, not from primitives. This distinguishes it from sibling tools like pbi_create_visual and pbi_compose_page, which are lower-level. The verb 'Construye' and resource 'dashboard completo' are specific and unambiguous.
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 implies usage for high-level dashboard creation when there is a defined objective, contrasting with primitive operations. It does not explicitly name alternative tools or exclusions, but the 'no desde primitivas' phrase provides clear context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Las anotaciones no aportan información porque todos los hints son false. La descripción añade detalles cruciales: no se copia el texto del título (contenido) y el cruce de tipos es rechazado. Esto va más allá de simplemente decir 'copia' y ofrece contexto sobre límites y riesgos.
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?
La descripción es breve y bien estructurada: una frase principal, una aclaración sobre el título y una restricción con justificación. No hay relleno ni redundancia; cada frase aporta información útil.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describe la acción principal, el matiz del título y la restricción de tipo, pero no aclara si el copiado puede ser entre páginas distintas, a pesar de que los parámetros source_page y target_page lo sugieren. Tampoco menciona el comportamiento ante errores. Dado que existe un esquema de salida, la falta de descripción del retorno es aceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
La cobertura del esquema es 0% y la descripción no menciona ningún parámetro concreto. No explica cómo identificar source_page, source_visual, target_page o target_visuals ni qué formato deben tener los identificadores, dejando al agente sin información adicional.
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?
La descripción comienza con 'Copia el formato de un visual a otros DEL MISMO TIPO', usando el verbo específico 'copia' y el recurso 'formato de un visual'. La restricción 'DEL MISMO TIPO' distingue claramente la herramienta de otras como pbi_duplicate_visual o pbi_set_visual_title.
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?
Se indica explícitamente cuándo no usar: 'Copiar entre tipos distintos se rechaza', lo que delimita el contexto de uso. No se nombra una alternativa directa, pero la advertencia de que Power BI podría rechazar el informe aclara los riesgos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are present (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds behavioral context beyond them: it states that the custom visual is registered in the report if not already present, and clarifies that the HTML is built in DAX (typically with VARs and CONCATENATEX). This is useful side-effect disclosure, though it doesn't cover all failure modes or behavior on existing visuals.
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 concise: two short paragraphs, with the primary purpose front-loaded. The parameter detail is inline and could be better formatted as a list, but it's efficient and free of fluff.
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?
Given the tool's complexity (5 params, nested position object, output schema present), the description provides key workflow context: the measure is pre-created via pbi_create_measure, the visual registers itself, and the HTML is constructed in DAX. It does not explain page/position details, but for a Power BI-focused audience these are familiar. The output schema likely covers return values, so the description needn't.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% schema description coverage, so the description must compensate. It only explains html_measure, giving an example, but leaves page, position, title, and request_id undocumented. This is insufficient for a tool where the user must supply page and position correctly.
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: 'Crea un visual "HTML Content"' (creates an HTML Content visual) and explains its function: renders HTML/SVG from a measure. This clearly distinguishes it from generic siblings like pbi_create_visual or pbi_add_custom_visual by naming the exact visual type.
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 explicitly instructs that the measure must be created separately with pbi_create_measure, providing a direct cross-reference to a sibling tool. It also gives an example measure name ('[HTML Panel EVM]'). This gives clear context for when this tool is appropriate, though it does not state explicit 'when-not-to-use' scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations that declare destructiveHint=true, the description adds the crucial requirement 'confirm=true' to actually execute the deletion. It also mentions the side effect of removing the bookmark from the index, providing useful behavioral context beyond the structured metadata.
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 two short sentences, front-loads the verb and resource, and wastes no words. It efficiently conveys the action, the index side effect, and the destructive confirmation requirement.
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 a simple delete operation with an output schema and annotations, the description is mostly complete. It warns about destructiveness and the confirm flag, but does not mention failure scenarios (e.g., bookmark not found) or what happens if confirm is false. Acceptable for simple tool.
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 carries the burden of explaining parameters. It explains that 'confirm' must be true for deletion, and 'name' is implicitly the bookmark to delete, but 'request_id' remains undocumented. Partial compensation, but not complete.
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 clearly states the action 'Borra un marcador' (deletes a bookmark) and specifies the additional behavior 'lo quita del indice' (removes it from the index). This distinguishes it from sibling tools like pbi_create_bookmark or pbi_list_bookmarks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you want to delete a bookmark) but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The destructive warning hints at caution but does not elaborate on when to avoid use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behavioral traits: files are written to `outputs/excel/` and never inside the PBIP, existing names are not overwritten, injected formulas are neutralized, and the XLSX is reopened before reporting success. It also clarifies that query execution is read-only DAX. These details significantly exceed the simple boolean 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 front-loaded with a clear purpose and uses three focused paragraphs to convey behavior, safety, and conditions. Each sentence contributes information, though the middle paragraph is dense with multiple details and could be slightly restructured for readability.
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 a complex tool with multiple sheets, conditional behavior (PBIP active, DAX query), and file output, the description provides strong coverage of side effects, output location, and safety checks. However, it omits explicit parameter semantics and error scenarios, though an output schema exists to cover return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for `source` (auto|live|pbip) and `query` (read-only DAX against Desktop with truncation declaration), but it does not explain `max_rows`, `file_name`, `include_audit`, or `include_report`. With 0% schema description coverage, the description should compensate more; the remaining parameter semantics are left to inference from their names.
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: 'Exporta la informacion disponible a un libro Excel verificado,' clearly stating it exports available information to a verified Excel workbook. It further details the sheet types (summary, tables, columns, measures, relationships, pages, visuals, audit), which distinguishes it from sibling export tools like HTML or PDF exporters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides contextual usage details such as supported `source` modes and optional DAX query execution, but it does not explicitly state when to prefer this tool over alternatives like pbi_export_page_html or pbi_generate_pdf_report. No exclusions or when-not use cases are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that output is saved to outputs/ and includes the audit scoring, providing some context about side effects. Annotations are all false and unhelpful, so the description carries the burden; it does not mention whether the tool modifies the model/report or if there are prerequisites, leaving gaps in behavioral transparency.
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 concise (two sentences), front-loaded with the core purpose and output location, and efficiently lists the documentation contents without redundancy.
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 a zero-parameter generation tool, the description adequately covers what is produced (model, report, audit) and where. It could mention prerequisites like a selected model or open report, but the output schema likely covers return details, making the description reasonably complete.
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?
The tool has zero parameters, and the empty schema provides no semantic information. The description's focus on what the documentation includes effectively compensates for the lack of parameters, meeting the baseline for a no-parameter tool.
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 clearly states the tool generates complete technical documentation in Markdown, listing specific contents (model, report, audit). It distinguishes itself from sibling tools like pbi_document_model and pbi_document_report_layout by being comprehensive and including the audit score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the word 'complete' and the enumerated contents, suggesting it is the all-in-one documentation option. However, it does not explicitly state when to use this tool versus alternatives like pbi_document_model or pbi_audit_project, nor provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds domain context about what a preset represents, but does not disclose any additional behavioral traits such as filtering, pagination, or response size.
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 two concise sentences in Spanish. It front-loads the primary purpose and then clarifies the meaning of a preset, with no redundant words or irrelevant details.
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 a zero-parameter read-only list tool with an output schema, the description is sufficiently complete. It explains what is returned (presets with blocks) and the underlying concept, though it does not detail how presets might be used in page composition workflows.
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?
The tool has zero parameters, and the description correctly focuses on what the tool returns rather than argument details. With no parameters to document, the baseline of 4 applies; the description adds conceptual clarity about preset intentions.
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 clearly states the tool lists available page presets with their component blocks. It also defines the concept of a preset as a page intention, distinguishing this from other listing tools like pbi_page_building_blocks or pbi_list_themes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to browse preset page layouts before composing a page, but it does not explicitly mention when to use it versus alternatives. No exclusions or direct comparisons to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces a read-only list operation. The description adds value by explaining that pending journals contain originals and that only_pending=false includes closed ones, but does not disclose any other behavioral traits such as pagination or ordering. 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 three sentences, each serving a purpose: what the tool does, what 'pending' means, and the optional parameter behavior. No wasted words or redundancy.
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?
Given that an output schema exists and the tool is a straightforward list operation, the description adequately covers scope ('del proyecto activo') and filtering semantics. It doesn't describe return values, but the output schema handles that. Minor gap: no mention of what fields are returned per journal, but not required for the tool's basic use.
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?
The schema provides no description for the only_pending parameter, so the description carries the sole burden. It explains that setting only_pending=false lists closed journals as well, which clarifies the parameter's effect beyond the raw schema. The boolean nature and default are implicitly clear.
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 starts with a clear verb 'Lista' and specific resource 'journals del proyecto activo', distinguishing it from sibling tools like inspect_journal and recover_from_journal. It also clarifies the meaning of 'pending', leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context about what pending journals are and the effect of the only_pending parameter, but it does not explicitly state when to use this tool versus alternatives like pbi_inspect_journal or pbi_recover_from_journal. Usage is implied rather than explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the readOnlyHint and openWorldHint annotations. It discloses that the analysis is lexical, detecting only written references and not dynamically constructed ones, which is a critical limitation. It also mentions the inclusion of broken references, providing useful insight into the tool's behavior.
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 concise and well-structured. It opens with a one-line summary of the tool's purpose, followed by two sentences that detail the outputs and the lexical analysis limitation. Every sentence adds valuable information without unnecessary verbosity.
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?
The description covers the core functionality comprehensively: direct dependencies, transitive closure, reverse dependencies, and lexical limitations. An output schema exists, so return values need not be described. The main gap is the unexplained `source` parameter, which prevents a perfect score.
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?
The schema has 0% description coverage, leaving the burden on the description. The description explains that `depth` controls the transitive closure depth and implicitly identifies `name` as the measure name. However, the `source` parameter is not explained at all, leaving a gap in understanding what values it accepts and how it affects the analysis.
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 clearly states the tool's purpose: it returns measure dependencies, both direct and transitive, plus reverse dependencies. It distinguishes itself from siblings like pbi_column_dependencies by focusing on measures. The phrase 'De que depende una medida y quien depende de ella' captures the bidirectional dependency analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for understanding measure dependencies but does not explicitly state when to use this tool over alternatives such as pbi_column_dependencies or pbi_run_dax. There is no when-not-to-use guidance or mention of alternative tools. The context is clear enough for an informed agent, but the lack of explicit exclusions prevents a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by explaining the tool's conservative approach ('NO mueve lo que ya esta bien') and by disclosing the dry-run behavior ('dry_run=true devuelve el plan sin escribir'). It does not contradict the annotations (readOnlyHint=false, destructiveHint=false), and it adds useful context about what the tool actually does during execution.
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 concise, front-loaded with the main purpose, and every sentence earns its place. It uses a short opening sentence, followed by detailed behavior and the dry-run note, with no redundant or filler text.
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?
Given that an output schema exists, the description doesn't need to explain return values. It covers the tool's scope, key behaviors, and the dry-run option. It could mention prerequisites or side effects, but for a layout normalization tool with these annotations and schema, it is reasonably complete.
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?
Schema description coverage is 0%, so the description must compensate. It explains the 'dry_run' parameter's semantics ('devuelve el plan sin escribir'). The 'page' parameter is self-explanatory, but 'request_id' is not explained at all. Partial compensation for parameter clarity.
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 clearly states the tool's function: to fix fixable issues on a page without rearranging it entirely. It lists specific actions (brings into canvas, resizes too small, respects margins) and explicitly distinguishes itself as a conservative correction, which differentiates it from sibling tools like pbi_arrange_visuals or pbi_align_visuals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for pages with minor layout issues that need conservative fixing, and it mentions not moving elements that are already fine. However, it does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or direct comparisons to sibling tools. The context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly=false and destructive=false, but the description adds meaningful behavioral context: it moves overflowing items inside the canvas, raises too-small items, respects margins, leaves compliant items untouched, and compares audit score before/after. It does not mention dry_run behavior or reversibility, but it adds value beyond 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 compact and front-loaded: the first sentence states the core purpose, followed by three short behavioral clauses and one comparison clause. Every sentence adds meaningful information with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core transformation behavior and audit comparison, and an output schema likely covers return values. However, it omits the meaning of dry_run (which defaults to true) and any prerequisites or side effects, leaving a meaningful gap for a mutating tool with sparse schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (dry_run, request_id) with 0% description coverage, and the description does not mention either parameter. Since dry_run defaults to true and controls whether changes are actually applied, omitting it from the description is a significant gap; the agent must infer its meaning solely from the parameter name.
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 'Normaliza la geometria de TODAS las paginas del informe', a specific verb+resource+scope statement. It clearly distinguishes itself from sibling pbi_normalize_page_layout by applying to all pages, and details what normalization entails (fitting into canvas, minimum size, margins).
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 provides clear context for what the tool does and its non-destructive-to-compliant-elements behavior ('No reacomoda lo que ya cumple'), but it does not explicitly name alternatives or list when-not-to-use scenarios. Since sibling pbi_normalize_page_layout exists, direct comparison would have made this a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true), the description adds substantial behavioral detail: without 'confirm' it returns a manifest without deleting; it only deletes recognizable journal directories; it never deletes loose files, symlinks, or broad roots; and it always preserves the newest journal and all pending journals. This greatly informs the agent of safety and 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 concise and well-structured: it opens with the purpose and a clear destructive warning, then details the safe behavior and retention guarantees. Each sentence adds essential operational context without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is destructive with 4 parameters and an output schema. The description thoroughly covers safety behavior and preservation guarantees, but omits semantics for 'days' and 'max_journals' that are necessary for an agent to use it correctly. The output schema likely covers return format, but parameter gaps make the description incomplete overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'confirm' parameter ('Sin confirm devuelve el MANIFIESTO...') but does not explain 'days', 'max_journals', or 'request_id'. These are critical for correct invocation (e.g., retention period and number of journals to keep), so the description is insufficient for parameters.
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 clearly states the tool's purpose: 'Aplica la politica de retencion a los backups' (applies retention policy to backups), and explicitly marks it as DESTRUCTIVA. This distinguishes it from sibling tools like pbi_backup_pbip_project (backup creation) and pbi_recover_from_journal (recovery), making it the deletion/retention tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it name exclusions. However, the context of retention policy and the destructive hint imply it is for cleanup operations. The safety boundaries (only journal directories with manifest.json, never loose files/symlinks) provide usage constraints but not explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds useful behavioral context: case-insensitive search, filtering by kinds, and a distinction for measures between name and expression matches. This enriches the agent's understanding of the tool's behavior.
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 concise, front-loaded with the main purpose, and uses clear formatting for parameter details. Every sentence adds value, and there is no unnecessary filler.
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?
Given the presence of an output schema and read-only annotation, the description does not need to explain return values. It covers the core behavior and important nuances (case-insensitivity, kinds, name-vs-expression), though it omits details about `limit` and `source`. Overall, it is sufficiently complete for a search tool.
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?
Schema description coverage is 0%, and the description only explains `term` and `kinds`, adding meaning like case-insensitivity and filter types. However, `limit` and `source` are left undocumented, leaving gaps that the schema does not fill.
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 clearly states the tool's function: searching model objects by name and within measure DAX. The verb 'Busca' (search) is specific, and the resource 'objetos del modelo' is well-defined. This distinguishes it from sibling tools like list_tables or get_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding model objects by term, but it does not explicitly state when to use this tool over alternatives like get_object or list_measures, nor does it provide exclusions. The use case is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with readOnlyHint=true by stating 'No escribe nada.' It adds behavioral context beyond annotations by explaining how it determines next steps and mentions the Desktop-open blocker for TMDL, which is useful cautionary context.
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 moderately concise, with the core purpose stated in the first line. The opening metaphor about 132 tools is slightly extra but reinforces the tool's role; otherwise each sentence contributes useful information.
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 a starting-point tool, the description covers the main behavior, outputs common_tasks, and the safety guarantee. The presence of an output schema reduces the need to detail return values; the only real gap is the undocumented request_id parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional request_id with no schema description and 0% coverage. The description never mentions request_id, so it adds no semantic value for parameters; it does not compensate for the low schema coverage.
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 clearly identifies the tool as an entry point that inspects real state and proposes concrete next steps, including exact tool names and reasons. It distinguishes itself from the many sibling tools by explicitly saying 'Empieza por aqui cuando no sepas que sigue.'
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 explicitly states when to use: 'Empieza por aqui cuando no sepas que sigue.' It also describes the conditions it evaluates (active project, model vs report, empty, Desktop open), but does not explicitly state when not to use it beyond noting it writes nothing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint, but the description adds valuable behavioral details: it validates three specific aspects, reports errors with their JSON paths, and explicitly states it writes nothing ('No escribe nada'). This enriches the agent's understanding beyond the structured 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 two short paragraphs, front-loaded with the main purpose. Every sentence adds value: the first states the core function, the second explains the error reporting format and side-effect-freeness. No redundant information or filler.
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 a single-parameter tool with an output schema present, the description covers key aspects: what is validated, error format, and that it is non-mutating. It does not mention prerequisites like having a model selected, but the sibling set includes model-selection tools, and the validation scope is clear enough.
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?
The input schema has zero coverage and only declares 'spec' as an object. The description helps by implying a structure via the example JSON path (`$.visuals[2].fields.values[0]`), indicating the spec contains visuals with fields. However, it does not fully describe the expected object shape, dependencies, or validation contract, so agents may still need to infer from sibling tools.
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 states a specific action (validates a spec) and enumerates the validation dimensions: schema, references against the model, and geometry. It clearly distinguishes this tool from siblings like pbi_apply_page_spec (which applies) and pbi_preview_page_spec (which previews), and explicitly notes it writes nothing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage context (validating before correcting errors) through 'para que se puedan corregir sin adivinar', but it does not explicitly state when to use this tool over alternatives such as pbi_validate_generated_page or pbi_diff_page_spec. No exclusions or alternative tool mentions are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation, so the description's added context—listing dependency types and the 'tells if something breaks' behavior—provides meaningful transparency beyond the annotation. No contradictions found.
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 two concise sentences, front-loaded with the core purpose and followed by a practical use case. Every word earns its place without fluff.
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?
The description covers the essential use case and dependency types, and an output schema likely documents return values. It lacks details like interpretation of results or limitations, but given the schema and annotations, it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters, but it only indirectly references 'column' and 'table' without detailing them. The 'source' parameter is not mentioned at all, leaving ambiguity about its purpose (e.g., live vs. other sources).
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 clearly states the tool identifies what uses a column—measures, calculated columns, relationships, and hierarchies—which is a specific verb+resource. It also distinguishes itself from sibling tools like pbi_measure_dependencies by focusing on column dependencies rather than measure dependencies.
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 explicitly says to use it before hiding or deleting a column to check if anything breaks, providing a clear when-to-use scenario. It doesn't mention when not to use it or name alternatives, but the context is specific enough for agents to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses that the tool writes the bookmark file and updates the index, warns that Power BI won't show the bookmark without the index, and mentions the return value ('usage'). This adds behavioral context beyond the annotations, which already indicate a non-read-only operation. 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 a compact paragraph that front-loads the purpose, then explains side effects, param hints, and return value. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and a mutation operation, the description covers the core purpose and key side-effects but omits several parameter semantics (e.g., overwrite, suppress_data). The output schema likely documents the return value, but parameter gaps reduce completeness.
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?
The schema has 0% description coverage, so the description carries the burden. It explains `page`, `filters`, and `target_visuals` with useful detail, but leaves `display_name` (required), `overwrite`, `name`, `request_id`, `suppress_data`, and `suppress_display` unexplained. This is a partial compensation, not complete.
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 clearly states the tool creates a bookmark ('Crea un marcador') and defines what a bookmark is (a report state to return to via a button). It distinguishes from siblings like pbi_list_bookmarks and pbi_delete_bookmark by describing the creation and index-writing behavior.
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 provides clear context for when to use the tool by explaining the creation workflow and the dependency on the index, but it does not explicitly name alternatives or exclusions. The context is sufficient to infer this is the creation tool among bookmark-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the minimal annotations by disclosing that column inference executes the DAX against the open model and that the tool writes TMDL requiring a closed project. This adds meaningful operational context. However, it does not explain behavior of the 'overwrite' parameter or potential side effects of executing the expression.
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 concise but information-dense, with each sentence adding value: use case, technical mechanism, and prerequisite. No fluff or repetition, and key details are front-loaded.
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?
Given the tool's complexity, the description covers essential operational constraints (model state, project state) and the core behavior. It does not describe return values, but an output schema exists. Missing details about overwrite semantics and error conditions are gaps, but overall it is fairly complete for a knowledgeable agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 full burden. It explains the 'columns' parameter well (inferred by executing DAX if not provided), but leaves 'overwrite', 'description', and 'request_id' unexplained. With 6 parameters and only one meaningfully detailed, compensation is incomplete.
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 starts with a specific verb+resource: 'Crea una tabla calculada (DAX) en el modelo .pbip.' This clearly distinguishes it from siblings like pbi_create_calculated_column or pbi_create_measure. The use-case explanation (unpivoting columns to rows) further clarifies its unique role.
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 a concrete use case ('diez metricas guardadas en diez COLUMNAS en vez de en filas') and explicit operational requirements (model open/selected for column inference, project closed for TMDL write). While it doesn't name alternative tools, the context makes appropriate usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: it 'deja activo' the project, uses relative paths to avoid machine-specific coupling, includes one page because a report without one won't open, and intentionally omits `sourceQueryCulture` with reasoning. These are meaningful behavioral details that the annotations (all false) do not cover.
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 organized into short paragraphs, each serving a purpose: purpose, workflow, technical rationale, and culture note. It is more detailed than strictly necessary but every sentence earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides rich rationale for design decisions, but with 9 parameters and zero schema coverage, the missing parameter semantics create a gap. An output schema exists, so return values are covered, but the description should do more to explain how input parameters affect the created project.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description doesn't explain most parameters. It only hints at the culture parameter through the `sourceQueryCulture` discussion, but out_dir, name, width, height, overwrite, page_name, request_id, and open_project remain semantically unexplained. The description adds some context but doesn't compensate for the high parameter count.
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 clearly states the tool creates an empty but valid .pbip project: 'Crea un proyecto .pbip vacio pero valido, y lo deja activo.' It also distinguishes this from siblings by framing it as the starting point for a file-path-based workflow, mentioning pbi_add_table_from_file as the next step — a specific verb+resource with clear scope.
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 gives clear when-to-use context: 'Es el punto de partida para armar un tablero solo con rutas de archivos' and outlines the intended workflow (create project, load data, compose pages). While it doesn't explicitly state when not to use it (e.g., converting an existing .pbix), the workflow guidance effectively implies its place among alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly discloses that the tool writes a file (`pbi-brief.json`) next to the .pbip, outside .Report/.SemanticModel, and that overwriting is normal because dashboards change purpose. It also explains that the agent must not fabricate answers. This adds meaningful behavioral context beyond the sparse annotations and does not contradict them.
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 purposeful. It front-loads the main verb and resource, uses a bolded warning for the most important behavioral rule, and packs useful details about parameter semantics and file storage. While not as terse as possible, every sentence adds relevant context.
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 a tool that writes a brief file, the description is fairly complete: it explains the file location, why it is stored there, the human-interaction requirement, and key parameters like delivery and critical_fields. The presence of an output schema reduces the need to describe return values. Some parameter descriptions are missing, but the overall context is sufficient for effective use.
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?
The input schema has 0% description coverage, so the description carries a heavy burden. It does explain `delivery` (with enum values and meaning) and `critical_fields` (structure and purpose), and indirectly covers `purpose` and `audience`. However, several other parameters like `decisions`, `non_goals`, `request_id`, `key_questions`, and `update_cadence` are not described, leaving gaps.
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: 'Escribe el BRIEF DE INTENCION del tablero' (Write the intent brief of the dashboard). It clearly defines the artifact's role as governing other pieces and distinguishes it from sibling tools like pbi_get_brief by focusing on creation and intent capture rather than retrieval.
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 gives strong usage guidance: it explicitly says to ask the human before calling, lists specific questions to ask, and warns that an agent-invented brief is worse than none. It does not explicitly name alternative tools, but effectively communicates when not to use it by emphasizing that answers must come from the human.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide negative hints (readOnlyHint=false, etc.), placing the burden on the description. The description does add context about the contract structure, the mandatory shared key, and its role in validation. However, it does not disclose whether writing overwrites an existing file, what side effects occur (e.g., creating/updating the file), or any permission requirements. This is moderate transparency—useful context but not full behavioral disclosure.
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 moderately lengthy but each sentence serves a purpose: it states the action, corrects a common misconception, gives the dataset schema, explains the key's importance, and notes the validation workflow. It is well-structured and front-loads the main verb. It could be slightly condensed, but it earns its length by preventing misuse.
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?
The tool has an output schema (not shown), so return values need no explanation. The description covers the main action, the conceptual background, the dataset shape, and the relationship to validation tools. It does not explain optional parameters (name, request_id) or overwrite behavior, but for a definition/write tool with a well-defined primary parameter, it is reasonably complete.
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?
With schema description coverage at 0%, the description must compensate. It does so for the main `datasets` parameter by providing a detailed inner structure: [{name, key, columns: [{name, type, required?}], emitted_by?, description?}], and explicitly states the `key` is mandatory. However, it does not explain the `name` and `request_id` parameters, leaving some semantic gaps. This is strong compensation for the primary param but incomplete for all params.
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 clearly states "Escribe el CONTRATO del puerto del ecosistema (pbi-port-contract.json)" — a specific verb (write) and resource (the port contract file). It distinguishes the tool from pbi_check_contract (which validates) and pbi_define_brief (which defines the brief), and clarifies the port is a data contract, not an API bus. This makes the tool's purpose unambiguous.
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 the contract 'vive versionado junto al .pbip' and that it is validated with pbi_check_contract, giving clear context for when to use this tool (to define/write the contract) versus when to use the validation sibling. It also explains the rationale for the contract approach. However, it lacks explicit 'when not to use' or alternative tool exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the side effect of disabling: Power BI removes automatic date tables (LocalDateTable_*) when reopening the .pbip, lightening the model. With annotations all false and unhelpful, the description carries the behavioral disclosure burden and does so adequately.
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 concise and front-loaded with the main action, followed by a practical benefit and a prerequisite. Each sentence adds value without unnecessary fluff.
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?
Given the tool's simplicity and the presence of an output schema, the description covers scope ('solo modo pbip'), prerequisite, and a key side effect. It does not describe enabling behavior in detail, but the essential operational context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explicitly explain the 'enabled' or 'request_id' parameters. The word 'Activa/desactiva' implicitly maps to the boolean 'enabled', but the request_id parameter is completely unaddressed, requiring the agent to infer its purpose.
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 clearly states the tool activates/deactivates 'Auto fecha y hora' in pbip mode, using a specific verb and resource. It distinguishes itself from siblings by addressing a unique setting that no other tool mentions.
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: 'solo modo pbip' and 'Requiere proyecto .pbip activo' indicate when to use the tool. It does not explicitly name alternatives or exclusions, but the scope and prerequisite are well defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds that results include domain and severity, which is helpful context. However, it does not disclose further behavioral traits such as authentication, rate limits, or exact return structure beyond those fields.
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 a single, compact sentence that immediately communicates the resource and key attributes (domain, severity). It wastes no words and is appropriately front-loaded.
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 zero-parameter, read-only catalog tool with readOnlyHint annotation and an output schema, the description is complete. It clearly communicates the purpose and the included fields, making it sufficient for an agent to select and invoke the tool correctly.
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?
This tool has zero parameters, and the input schema is empty, so there are no parameter semantics to clarify. Per rubric, the baseline for 0 parameters is 4, and the description does not need to compensate for schema gaps.
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 clearly states it is a catalog of available audit rules with their domain and severity, which distinguishes it from sibling tools like pbi_list_autofix_rules. It uses a specific resource and conveys the listing nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage as a discovery/preflight tool for audit rules but does not explicitly state when to use it versus alternatives such as pbi_audit_project or pbi_list_autofix_rules. The guidance is 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint annotation by explaining edge-case behaviors: bookmarks missing from the index are invisible, and index entries without files break the panel, both silently. This is valuable context that annotations do not provide.
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 concise and front-loaded, with each sentence adding meaningful information. It is slightly cryptic due to Spanish phrasing and domain-specific terms, but remains appropriately sized and structured.
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?
With an output schema present, the description does not need to explain return values. It covers the tool's purpose and important edge cases, though it leaves 'index' and 'disk' somewhat undefined, which may be clear only in context.
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?
The tool takes no parameters, so there is nothing for the description to clarify beyond the schema. The baseline of 4 applies, and no additional parameter explanation is needed.
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 clearly states the tool lists report bookmarks and identifies inconsistencies between index and disk. It distinguishes itself from sibling tools like pbi_create_bookmark and pbi_delete_bookmark by focusing on enumeration and inconsistency detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description implies it is for inspecting bookmarks, but it does not state prerequisites, exclusions, or contrast with other bookmark-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation without destructive effects. The description adds a useful behavioral nuance: the internal ID remains unchanged, which helps agents understand side effects. It does not cover all possible impacts (e.g., references), but given the simple operation this is adequate.
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 a single, concise sentence with no redundant information. It is front-loaded with the action and immediately conveys the key detail about internal ID stability.
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?
Given the tool's simplicity and the presence of an output schema (not shown), the description is mostly complete. It could mention return values or error conditions, but the core behavior is clearly described. The annotation already covers safety aspects, so this is near-complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, leaving only property titles 'Page' and 'New Name'. The description does not explain what the 'page' parameter expects (name, ID, or object reference) nor any constraints for 'new_name'. This is a significant gap because the description fails to compensate for the lack of schema details.
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 clearly states the tool changes a page's visible name and notes that the internal ID does not change, providing a specific verb and resource. This distinguishes it from sibling tools like duplicate or delete page, as it is solely for renaming.
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 implies when to use the tool (renaming a page) and is unambiguous for that action. It does not explicitly mention alternatives or exclusions, but for a rename operation this is acceptable and clear enough for an agent to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), the description provides meaningful behavioral context: each action uses transaction/verification/rollback, failures are reported without stopping others or hiding them, and confirm=true is required—all useful for safe invocation.
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?
Two concise sentences, front-loaded with the main action and a critical prerequisite; no filler.
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?
With output schema present and annotations covering destructive/read-only, the description adds essential failure-handling behavior and a guard condition. Missing request_id semantics and action structure detail, but overall adequate for a complex destructive operation.
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?
Schema coverage is 0%; the description gives semantic weight to the 'actions' parameter by sourcing it from pbi_plan_audit_fixes and to 'confirm' by making it a mandatory gate, but request_id is never explained and the open-ended action objects are not detailed.
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 states 'Aplica las acciones devueltas por pbi_plan_audit_fixes' (Applies the actions returned by the plan tool), clearly identifying a verb (applies), a resource (actions), and the source, distinguishing it from sibling pbi_plan_audit_fixes and other 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?
It specifies a prerequisite 'Requiere confirm=true' and implicitly situates the tool after pbi_plan_audit_fixes, but doesn't explicitly name alternatives or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false), and the description reinforces this by stating 'Escribe el tema' (writes the theme) and 'Escribe en el informe (PBIR)' (writes to the PBIR report). It goes beyond annotations by specifying the exact side effects: modifying report.json, returning canvas/grid/typographic scale, and the recommendation to close the project. This gives the agent useful behavioral context about what changes and what to expect.
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 well-structured in three short paragraphs: the first gives the main action and output, the second details the write and return values, the third offers a practical warning. Every sentence adds value, there is no redundant or filler content, and the key information is front-loaded. It is concise without sacrificing necessary detail.
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?
The presence of an output schema means the description doesn't need to detail return types, but it still mentions the return values (canvas, grid, typographic scale) as added context. It covers the side effect (writing report.json) and a critical prerequisite (closing the project in Power BI Desktop). It does not mention error scenarios, prerequisites beyond the closed project, or how to obtain a valid system value, but given the tool complexity and schema richness, the description is reasonably complete.
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?
The input schema has only two parameters (system, request_id) with zero descriptions, so the description must compensate. The name and description together make it clear that 'system' refers to the design system to apply, but the description does not define the expected format, where to obtain valid values, or any default behavior. It indirectly points to the existence of design systems (sibling pbi_list_design_systems), but this is not explicit. The semantics are inferable but not fully specified, meriting a mid-range 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 clearly states the action: 'Aplica el sistema al informe' (applies the system to the report) and immediately mentions the output: 'devuelve su rejilla' (returns its grid). It also mentions writing the theme and declaring it in report.json, and it distinguishes itself from the similar sibling pbi_compose_page by noting that manually placed items should use the same guides. This is a specific verb+resource+output, fully differentiated from siblings.
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 gives practical context: it should be used before manually placing items, as it ensures consistency with pbi_compose_page. It also provides a concrete operational guideline: 'conviene tener el proyecto CERRADO en Power BI Desktop' (it is advisable to have the project closed in Power BI Desktop). While it doesn't explicitly say 'do not use when...', the reference to pbi_compose_page and the manual placement workflow imply the intended moment of use, making the guidance clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the destructiveHint annotation by disclosing the confirm=true requirement, the return of the previous definition, and the journal-based restore capability. These are meaningful behavioral details that help the agent understand the tool's safety and recovery mechanisms. 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 extremely concise, two sentences long, with the core action first and important constraints immediately following. Every sentence earns its place with no redundant information.
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?
Given the destructive nature, the description adequately covers the key context: what it does, the confirmation requirement, and the recovery path via journal. The presence of an output schema likely covers return value details, and annotations cover destructiveness. It could mention error conditions, but the current level is sufficient for a delete tool.
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 must compensate. It explicitly explains the confirm parameter ('requiere confirm=true') but does not elaborate on page, visual_id, or request_id. The parameter names are relatively self-explanatory, but the description only partially covers the parameter semantics.
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 'Elimina un visual' clearly states the action (delete) and resource (visual), distinguishing it from sibling tools like pbi_delete_bookmark and pbi_delete_page. It also adds important context about destructiveness and confirmation, making the purpose unambiguous.
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 implies usage by framing it as a destructive operation that requires confirm=true, which signals when to use it (intentional deletion with confirmation) and cautions against careless use. It does not explicitly name alternatives or exclusion scenarios, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given readOnlyHint: true, the description adds value by specifying the concrete behavioral outputs (added, leftover, same visuals) and how missing pages are handled (reports that it will be created). This exceeds the annotation baseline without contradicting it.
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 three short sentences, front-loaded with the main action, and contains no redundant or filler content. Every sentence contributes meaningful information.
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 a diff tool, the description covers the primary behavior and outcome categories, and the existence of an output schema reduces the need to document returns. It assumes prior knowledge of what a 'page spec' is, but this is reasonable given the sibling tool ecosystem.
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 coverage, the description must clarify parameters, and it partially does: 'spec' is identified as the proposed spec, and 'page' is implied to be an existing page (or missing → creation). However, the structure of a spec is not explained, and the nature of 'page' (e.g., name vs. ID) is left vague.
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 clearly states it compares a spec against an existing page to identify added, removed, and unchanged visuals, which is a specific and distinct function from sibling tools like apply or preview. The verb 'diff' is effectively explained through the listed outputs.
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 phrase 'before applying it' provides clear usage context, implying this is a dry-run comparison preceding pbi_apply_page_spec. It does not explicitly exclude other tools or mention alternatives, but the temporal guidance is useful and clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses meaningful behavioral details: it detects folder types (TMDL/PBIR), returns a summary with warnings, and gives an example warning. Annotations (idempotentHint: true, readOnlyHint: false) are consistent with the description. It could go further on side effects, but this exceeds the bar.
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?
Three sentences, perfectly front-loaded with the primary action, followed by detection behavior and a parameter explanation. Every sentence earns its place with zero fluff.
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 a moderate-complexity tool with an output schema, an idempotency annotation, and a well-covered single parameter, the description covers the essentials: behavior, detection, return value, and parameter format. No major gaps identified.
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?
With 0% schema description coverage, the description must compensate for the single 'path' parameter — and it does with a dedicated sentence: '`path`: ruta al archivo .pbip o a su carpeta.' This fully explains the only parameter, including both accepted input forms.
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 uses a specific verb+resource: 'Opens a .pbip project and marks it as active project.' It clearly explains the scope (detects .SemanticModel and .Report folders, returns a summary with warnings) and distinguishes itself from siblings like pbi_create_pbip_project or pbi_open_in_desktop. No other sibling has this open/activate purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is a prerequisite for working with a project (it 'marks it as active project'), which suggests a workflow, but it doesn't explicitly state when to use it vs. alternatives. It provides no 'when not to use' guidance or explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds valuable context: it explains that with dry_run=false the tool applies corrections and compares scores before/after. This discloses the mutating behavior and the dry-run safeguard, going 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (three sentences), front-loaded with a clear summary ('Checklist de pre-entrega con plan de correccion'), and contains no redundant information. Every sentence adds functional value.
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?
Given that an output schema exists, the description does not need to explain return values. It covers the core workflow (audit, checklist, corrections, optional apply) and the dry_run behavior. However, it omits details about request_id and potential side effects of applying corrections, leaving minor gaps.
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?
The description explicitly explains the dry_run parameter (with dry_run=false it applies corrections), which is key. However, it does not mention request_id at all, and since schema_description_coverage is 0%, the description only partially compensates for the undocumented parameters.
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 clearly states the tool's function: it audits the project, produces a checklist of blockers, proposes automatic corrections, and optionally applies them when dry_run=false. It uses a specific verb ('Audita', 'produce') and distinguishes itself from siblings like pbi_audit_project and pbi_apply_audit_fixes by combining audit and correction application.
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 clearly implies a pre-delivery usage context ('Checklist de pre-entrega') and explains the workflow with dry_run. However, it does not explicitly mention when to choose this tool over alternatives such as pbi_audit_project or pbi_apply_audit_fixes, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Solo lectura' (read-only), but the annotations set `readOnlyHint: false`. This is a direct contradiction, undermining the agent's ability to trust the tool's side-effect profile. Although other behavioral details are provided (detected issues, queries, consequences), the contradiction forces a score of 1 per evaluation rules.
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 well-structured and concise, with each sentence providing essential information: purpose, complementary relationship, detection criteria, and parameter roles. No filler; it is front-loaded and stays focused.
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's moderate complexity, the description covers the key aspects: what it does, which specific data anomalies it detects, what each finding includes, that it is read-only, and how parameters affect behavior. The presence of an output schema means return values need no explanation, so this description is complete for agent usage.
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%, so the description fully compensates by explaining both parameters: `tables` scopes the work, and `max_columns` prevents timeout on large models. This adds meaningful context beyond the bare type information in the schema.
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 uses a specific verb 'Perfila' (profiles) with a clear resource ('VALORES del modelo'), and explicitly distinguishes itself from pbi_audit_model by stating it reviews data values rather than structure. This makes the tool's purpose unmistakable and differentiates it from its sibling.
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 explains when to use this tool instead of pbi_audit_model, noting that structural audits miss data-level issues like percentages outside 0-100. It also provides practical usage guidance for parameters, such as using `tables` to limit scope and `max_columns` to avoid timeouts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, but the description adds a non-obvious behavioral rule: unmentioned pages are moved to the end while preserving their relative order. This goes beyond what annotations provide and clarifies the side effect on the full set of pages.
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 two short sentences, front-loaded with the primary action, and each sentence adds unique information. No redundant or filler content, making it highly concise and efficiently structured.
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?
The tool is relatively simple with 2 parameters and an output schema present. The description covers the core functionality and the most important parameter behavior. It omits explanation for 'request_id', but given the optional nature and existence of an output schema, the description is sufficiently complete for an agent to invoke the tool correctly.
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?
Schema description coverage is 0%, so the description must carry the burden. It clarifies that the 'order' array accepts ids or visible names, which explains the main parameter's items. However, the optional 'request_id' parameter is not mentioned, leaving its purpose unclear. Partial compensation, but not complete.
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 begins with 'Fija el orden de las paginas del informe' which clearly states a specific action (fixing/ordering) on a specific resource (report pages). This distinguishes it from sibling tools like rename_page, delete_page, or duplicate_page, making the purpose unambiguous.
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 how to specify pages ('Acepta ids o nombres visibles') and the behavior of unmentioned pages ('Las paginas que no menciones quedan al final, conservando su orden relativo'). This provides clear usage context, though it does not explicitly mention when not to use this tool or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (all false, giving no safety profile), the description discloses important behavioral traits: it fails loudly instead of silently doing nothing, and it validates the destination against the model before writing, rejecting with field_not_found if invalid. This adds meaningful context about error handling and validation, though it omits details about reversibility or permissions.
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 compact and well-structured. Each sentence serves a purpose: the first states the core action, the second defines the parameter formats and scope, and the third clarifies validation and error behavior. There is no fluff or redundancy.
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?
The description covers the essential aspects: purpose, parameter format, constraints, and error behavior. It does not explain prerequisites like which model must be open, but the output schema exists (which likely covers return values) and the tool's scope is well-defined. Given the large sibling set, the description adequately distinguishes the tool but could benefit from an explicit usage scenario.
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?
With 0% schema description coverage, the description compensates by explaining the format of old_ref and new_ref ('Tabla[Campo]' or '[Medida]'). The remaining parameters (page, visual_id, request_id) are likely self-explanatory from their names, but the description does not add any semantics for them, so it only partially compensates for the coverage gap.
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: 'Sustituye una referencia de campo dentro de un visual' (replaces a field reference within a visual). It also explains the reference format and explicitly distinguishes itself from other visual operations by stating it works on existing projections and does not create new roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by specifying constraints (only works on existing projections, does not create new roles) and error behavior (fails if old_ref is not referenced), but it does not explicitly mention when to use this tool versus alternatives. For example, it doesn't state 'use this for swapping fields, while pbi_set_visual_filter is for filtering'—such guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) cover the safety profile, and the description adds genuine context: it's a stateful selection ('para futuras operaciones') and discloses the exact pass-through contract ('TAL CUAL lo devuelve pbi_list_desktop_models') along with the anti-pattern it prevents (hand-extracting the port). No contradiction with annotations — re-selecting is indeed idempotent.
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?
Three tight sentences, each earning its place: purpose, when-to-skip-args, and how-to-pass-values. The bolded 'o' and inline format example aid scanning. Dense but efficient — zero filler.
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 a stateful selection tool with an output schema present, the description covers the core flows: single model, multiple models, and the value-passing contract. Minor gaps: no comment on error behavior when no models are open or on whether selection persists, and catalog remains undefined. Still, given the output schema handles return values, this is largely complete.
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?
Schema description coverage is 0%, so the description must compensate. It richly does for two parameters: port and connection_string are explained as interchangeable alternatives with a concrete format example and 'don't transform the value' instruction. However, the `catalog` parameter is never mentioned, leaving one third of the API surface undocumented in both schema and description.
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?
Uses a specific verb with resource and scope: 'Selecciona el modelo local activo para futuras operaciones' (selects the active local model for future operations). This crisply distinguishes it from ~140 siblings like pbi_list_desktop_models (listing), pbi_define_port_contract, and pbi_test_connection. The purpose is unmistakable even without reading further.
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?
Excellent when/when-not guidance: single open model → no args needed; multiple models → pass `port` or `connection_string`. It explicitly references the companion tool pbi_list_desktop_models as the source of values and explains the pass-through contract so the agent doesn't transform input. Loses a point on not explicitly naming sibling alternatives to rule out, and doesn't state what happens when called with no args if multiple models are open.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details: the `order` array should be sorted from lowest to highest Z, the last item ends up on top, and unmentioned visuals are placed above while preserving their relative order. This goes beyond the sparse annotations (all false) and explains the tool's non-obvious behavior. No contradictions 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 concise with two sentences, front-loading the purpose and then explaining the key parameter. Every sentence provides value, with no fluff or redundancy.
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?
The description provides enough context for an agent to invoke the tool correctly: it defines the Z-order behavior and handles edge cases (unmentioned visuals). An output schema exists, so return values don't need description. Missing minor details like page identifier format or error handling, but these are not critical for a simple reordering operation.
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?
The description adds essential semantics for the `order` parameter, explaining it expects visual IDs and how the ordering interpretation works (lowest to highest Z, last is on top, unlisted visuals go above). This compensates for zero schema parameter descriptions, though `page` and `request_id` remain unexplained. The main parameter's meaning is significantly clarified.
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 clearly states the tool sets the Z order of visuals on a page ('Fija el orden Z de los visuales de una pagina'), using a specific verb and resource. It distinguishes from sibling tools like pbi_arrange_visuals or pbi_align_visuals by focusing specifically on layer ordering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly compare this tool to alternatives or state when to use it versus other layout tools. However, the tool name and introductory sentence make the use case clear (changing Z-order), so usage is implied. Lacks explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly discloses behavior: it validates max_files, max_total_mb, and extensions, uses temporary Graph URLs, verifies size and SHA-256, and publishes to outputs/sharepoint/. It also explains failure atomicity (removes staging, no partial folder). The read-only claim refers to remote SharePoint, not contradicting readOnlyHint:false which may reflect local writes.
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 concise and well-structured, with clear front-loaded purpose, a step-by-step process, failure behavior, and remote safety statement. Every sentence adds value with no redundancy.
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?
The description covers the tool's core workflow, validation, atomicity, and remote read-only nature, which is substantial for a complex download operation. The presence of an output schema reduces the need to explain returns. However, it omits guidance on recursive behavior and lacks explicit usage alternatives, making it nearly complete but not fully comprehensive.
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?
Schema description coverage is 0%, so the description must compensate. It explicitly explains the semantics and validation for max_files, max_total_mb, and extensions, with an example for extensions. However, it does not describe site_url, folder_path, library, or recursive, leaving significant gaps in parameter understanding.
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 clearly states the tool downloads a SharePoint folder to outputs/ in an all-or-nothing manner. It uses a specific verb ('Descarga') and identifies the resource, distinguishing it from sibling tools like pbi_sharepoint_list_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on what the tool does but does not explicitly state when to use it versus alternatives or exclude other tools. It mentions it is a remote read-only download, which implies safe usage, but does not name alternative tools or conditions for non-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the readOnlyHint annotation: it follows Graph pagination, can traverse subfolders recursively, and details the app-only authentication mechanism, including that secrets are only read from environment variables and never accepted or returned. This is rich, relevant transparency.
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 concise and well-structured: three short paragraphs front-loading the primary purpose, then usage details and authentication constraints. Every sentence contributes meaningful information without redundancy.
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?
The description covers the core aspects: connection, purpose, pagination, recursion, and authentication. It does not describe return values, but an output schema exists. It could mention error conditions or response structure, but overall it is adequately complete for a read-only listing tool.
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 schema description coverage at 0%, the description must compensate. It explains site_url, library, and folder_path, and implies max_items and recursive through 'limite total explicito' and 'recorrer subcarpetas', but does not explicitly define all parameters or their formats. Partial coverage with gaps.
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 clearly states the tool's purpose: 'Conecta con SharePoint Online y lista una carpeta mediante Graph.' It specifies the action (list), resource (folder), and method (Graph), and distinguishes itself from siblings like pbi_sharepoint_download_folder by focusing on listing rather than downloading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about what the tool does and how it connects, but does not explicitly state when to use it versus alternatives. The use case is implied (listing folder contents without downloading), and no exclusionary guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds meaningful context: checks broken references and geometry, and emphasizes deeper validation beyond mere write success. This goes beyond what annotations alone provide.
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?
Two concise sentences, front-loaded with the core action, followed by a clear usage context. Every word earns its place with no redundancy.
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?
Given the low complexity (one parameter), readOnlyHint annotation, and presence of an output schema, the description sufficiently covers what the tool does and when. It could clarify the result format, but that is likely handled by the output schema.
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?
Schema description coverage is 0%, so the description must compensate. The single parameter 'page' is referenced implicitly as 'una pagina', but the description does not specify the format or how to identify the page. However, the parameter name is self-explanatory, mitigating the gap.
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 uses a specific verb ('Verifica') and resource ('una pagina YA escrita'), and clearly states the scope: broken references and geometry. This distinguishes it from siblings like pbi_validate_page_spec, which validates specs, and pbi_apply_page_spec, which applies specs.
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?
Explicitly states when to use it: 'despues de aplicar un spec' to verify the result is genuinely valid, not just that writing succeeded. It does not mention alternatives or exclusions, but the timing and intent are clear in context of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds critical behavioral details: it verifies project state before applying, rejects changes if state differs, requires confirm=true, and explains the historical default change. This adds significant value beyond 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 moderately long but well-structured: it opens with the main purpose, then safety checks, then param clarification, then confirmation requirement with rationale. Every sentence adds value without redundancy.
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?
Given the output schema exists and annotations cover destructive nature, the description sufficiently covers the safety mechanism, the optional parameter, and the confirmation gate. It could elaborate on error scenarios beyond plan_operation_mismatch, but overall it's complete for its complexity.
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?
Schema description coverage is 0%, so the description must compensate. It explains expected_operation and confirm explicitly, but plan_token and request_id are not described. plan_token is inferable as the plan identifier, but request_id remains undocumented. Partial compensation.
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 clearly states the tool applies a plan calculated with pbi_plan_change or a dry_run. It distinguishes itself from sibling tools by specifying the source of the plan and the additional verification step, making its purpose distinct.
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 implies usage after plan generation and emphasizes the need for confirm=true. It does not explicitly name alternatives, but the context (plan_change vs apply) is clear. The expected_operation parameter is explained as a safety mechanism.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
La descripción revela varios comportamientos más allá de las anotaciones: valida todas las entradas antes de escribir, escribe en una sola transacción, y usa un solo SaveChanges para el modelo en vivo. Explica la semántica de 'count' y 'results', así como las restricciones de modos. Todo esto es valor adicional significativo que no está en las anotaciones.
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?
La descripción es concisa pero densa; arranca con el propósito y luego detalla aspectos técnicos en frases cortas. No hay relleno. La parte de count/results podría ser redundante si el output schema ya lo cubre, pero el nivel de detalle es aceptable.
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?
Cubre modos, validación, atomicidad, orden de resultados y significado de count/results. No explica 'hidden' ni 'request_id', pero son parámetros menores. Para un lote con validación y múltiples destinos, la descripción es bastante completa, especialmente si el output schema documenta los retornos.
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?
La descripción define el formato de 'columns' como lista de {table, column} y explica 'count' y 'results'. Sin embargo, no documenta 'hidden' ni 'request_id'; 'hidden' se deduce fácilmente, pero 'request_id' queda sin contexto. Dado que la cobertura del esquema es 0%, la descripción compensa parcialmente pero deja lagunas.
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?
La descripción comienza con 'Oculta/muestra VARIAS columnas como un solo lote', que es un verbo específico con recurso claro. Aunque no compara explícitamente con pbi_set_column_visibility, el énfasis en 'VARIAS' y 'un solo lote' lo distingue claramente de herramientas de una sola columna.
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?
Da orientación concreta sobre cuándo usar cada modo: 'live' requiere Power BI Desktop abierto, 'pbip' cerrado, y 'auto' selecciona según el estado. Además, menciona que 'mode='both'' está deshabilitado temporalmente y recomienda 'auto' o 'pbip' para construcción desde cero. No alternativas para otros casos, pero el contexto de lote queda implícito.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by disclosing the detection mechanism (detects the Analysis Services engine on localhost:<puerto>) and enumerating the return values (port, connection string, catalog, table count). It does not mention edge cases (e.g., what happens if no reports are open), but for a read-only discovery operation, the provided detail is sufficient.
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 two succinct sentences in Spanish. It front-loads the primary verb and resource, then briefly explains the detection approach and output fields. Every sentence earns its place with no redundant or filler content.
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 zero-parameter, read-only tool with an output schema, the description is complete. It explains what the tool does, how it works, and what it returns. The readOnlyHint annotation covers safety, and the output schema handles detailed return structures, so nothing critical 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?
The tool has zero parameters, so the baseline is 4. The description correctly focuses on what the tool does rather than parameter details, and there is no missing parameter information to compensate for.
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 uses the specific verb 'Lista' and clearly identifies the resource: 'modelos de Power BI Desktop abiertos localmente'. It also lists the concrete outputs (puerto, connection string, catalogo, nº de tablas), making the tool's purpose distinct from sibling tools like pbi_list_tables or pbi_test_connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this tool when you need to list locally open Power BI Desktop models and get their connection info. However, it does not explicitly mention alternatives or exclusions, such as 'use pbi_select_model to work with a specific model' or 'use pbi_test_connection to validate connectivity'. The context is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, covering the safety profile. The description adds context about the active report and the fields returned, but does not discuss error conditions or dependencies beyond 'activo.' This is acceptable but not rich.
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 a single compact sentence with no wasted words. It front-loads the verb and resource, and every phrase contributes to understanding the tool's purpose and output.
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 zero parameters, a read-only annotation, and an existing output schema, the description covers the essential behavior, scope (active report), and returned fields. There are no critical gaps.
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?
The tool has zero parameters and schema coverage is 100%, so no parameter detail is needed. The description's mention of returned fields partially compensates for a no-parameter tool, but the baseline 4 for zero parameters is appropriate.
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 uses a specific verb 'Lista' and clearly identifies the resource as 'paginas del informe PBIR activo', enumerating returned fields (id, nombre, tamaño, nº visuales). This distinguishes it from sibling tools like pbi_list_visuals and pbi_list_bookmarks.
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 clearly states the tool operates on the active PBIR report, providing clear context for when to invoke it. It does not explicitly name alternatives or exclusions, but the scope is unambiguous for a list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by disclosing significant behavioral impacts: directQuery makes refresh disappear, requires foldable M queries, disables calculated columns/tables, and turns every visual into a server query. It also reveals return values (previous mode, number of partitions changed) for undoability and the requirement that the project be closed. This is rich, non-obvious behavioral context that the annotations do not convey.
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 well-structured and appropriately sized: it covers purpose, risks, return values, and a prerequisite in a few short sentences. There is no redundancy or fluff; every sentence adds distinct value, making it easy to parse quickly.
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's mutating and potentially disruptive nature, the description is thorough: it explains what changes, the directQuery-specific risks, what is returned (for undo), and a critical prerequisite (closed project). The presence of an output schema covers the return structure, so the description does not need to detail it further. Overall, it provides sufficient context for an agent to invoke the tool correctly.
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?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. It does mention the allowed modes for 'mode' and indicates the target is a 'table', but it does not describe the 'request_id' parameter or the expected format of 'table'. This leaves part of the parameter space unexplained, so the compensation is incomplete.
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 clearly states the tool changes the storage mode of a table, enumerating the exact allowed values (import, directQuery, dual). The verb 'Cambia' plus the resource 'modo de almacenamiento de una tabla' makes the purpose unambiguous and distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the consequences of using directQuery (refresh disappears, M query must be foldable, calculated columns/tables unavailable) which implicitly suggests when this tool might be used, but it does not explicitly state usage scenarios, alternatives, or exclusions. The prerequisite (project closed in Power BI Desktop) is a useful guideline, but it does not fully replace explicit when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide safety hints (all false), and the description adds substantial behavioral context: partial-update semantics ('lo no especificado se conserva'), the temporary disabling of mode='both', and the dependency of 'live' on Power BI Desktop being open. This goes beyond what annotations alone convey.
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 concise and front-loaded, starting with the core purpose in one sentence, then focusing on the important mode complication. It could be more structured, but every sentence contributes useful information without redundancy.
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?
Despite having 8 parameters and no schema descriptions, the description covers the most critical semantic (partial update) and the mode edge cases. An output schema exists, so return values need no explanation. It omits prerequisites like model selection, but that is likely handled by sibling tools and not essential for this tool's immediate use.
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?
With schema description coverage at 0%, the description compensates by explaining the 'mode' parameter in depth, including its default and trade-offs. It also clarifies that unspecified optional parameters are preserved, which adds meaning to expression, format_string, etc., even though they aren't individually detailed.
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 clearly states 'Actualiza una medida existente' (updates an existing measure), which is a specific verb+resource pairing. This distinguishes it from siblings like pbi_create_measure and pbi_delete_measure. It also adds the key nuance that unspecified fields are preserved, which further defines its scope.
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 the tool is for updating existing measures and provides detailed guidance on mode selection ('live' vs 'pbip' vs 'auto'), including requirements and default behavior. It does not explicitly name alternatives like pbi_create_measure, but the context is clear and no exclusions are needed beyond the mode caveats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Las anotaciones ya indican readOnlyHint=true, cubriendo la seguridad de la operación. La descripción añade valor conductual más allá de las anotaciones: detalla la verificación de referencias cruzadas, el hecho de que Desktop resuelve silenciosamente medidas borradas, y la precondición sobre el TMDL válido. Esto proporciona contexto importante sobre cómo se comporta la herramienta y por qué es necesaria.
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?
La descripción está bien estructurada: la primera oración da el propósito principal, y el segundo párrafo explica la característica clave y su justificación. Todas las oraciones aportan información útil, aunque el segundo párrafo es algo denso. En general, no hay relleno y la información se presenta de manera eficiente.
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?
Con 0 parámetros y un esquema de salida presente, la descripción se centra adecuadamente en el propósito y el comportamiento. Cubre los aspectos esenciales: qué valida, cómo lo hace (referencias cruzadas) y cuándo debe ejecutarse (TMDL válido). Los detalles de la respuesta los proporciona el esquema de salida, por lo que la descripción no necesita explicarlos.
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?
El schema de entrada no tiene parámetros (0 parámetros), por lo que la descripción no necesita explicar nada al respecto. Según la regla de cobertura del schema, al ser 100% y no haber parámetros, se otorga la línea base de 4.
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?
La descripción especifica claramente el verbo 'Valida a fondo' y el recurso 'proyecto .pbip activo', con alcance explícito (estructura, PBIR, TMDL). Además, introduce una característica distintiva: la verificación cruzada de `references` entre visual.json y el TMDL, lo que la diferencia de otras herramientas de auditoría como pbi_audit_project o pbi_validate_tmdl.
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?
La descripción incluye una condición explícita de uso: 'Solo corre si el TMDL es valido', proporcionando una clara indicación de cuándo no usar la herramienta (si el TMDL no es válido, la comparación sería ruido). No menciona alternativas, pero el contexto de validación profunda es suficiente para decidir su uso frente a herramientas similares.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds the specific audit categories, giving the agent a clear picture of what will be inspected without contradicting the read-only hint.
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 two sentences: the first establishes the tool's narrow purpose, the second lists the exact audit areas. No filler or redundancy.
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?
Given zero parameters and a read-only annotation, the description sufficiently covers the tool's behavior and scope. The output schema (present) handles return value details, so the description need not elaborate further.
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?
The tool accepts no parameters, so the description inherently covers all input needs; no parameter semantics are required.
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 states it audits only the PBIR report, excluding semantic model rules, and lists specific audit checks (empty pages, visuals without title, broken fields, duplicates, canvas sizes, page geometry). This clearly distinguishes it from siblings like pbi_audit_model.
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 explicitly says 'solo el informe PBIR (sin las reglas del modelo semantico)' indicating the tool is scoped to report-only audits, providing clear context for when to use it. It doesn't name alternative tools but its scope exclusion is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds valuable behavioral context by detailing what information the tool reveals (live layer status, write permissions, engine version constraints) and that it provides reasons for unavailable capabilities, which goes beyond the structured metadata.
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 concise and front-loaded: first sentence states the core purpose, second elaborates on specifics. Every sentence carries useful information with no redundancy or filler.
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?
Given the tool's simplicity (no params) and the presence of an output schema, the description adequately covers its purpose and key behavioral facets. It could mention what happens when the live layer is unavailable, but the output schema likely covers such details.
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?
The tool has zero parameters and the schema coverage is 100%, so there is nothing to explain. With no parameters, the baseline is 4, and the description appropriately focuses on the tool's output rather than input semantics.
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 clearly states the tool's function: to report what capabilities are currently available and what are not, with reasons. It specifies concrete aspects (live layer availability, .pbip writability, engine-version-dependent capabilities), distinguishing it from sibling tools like pbi_report_capabilities which likely focus on report-specific capabilities.
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?
Explicitly says an agent should consult this tool before planning, giving a clear when-to-use directive. It does not mention when not to use it or name alternative tools, but the context is strong enough to guide appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the sparse annotations (readOnlyHint=false, destructiveHint=false), the description discloses significant behavioral traits: it opens .pbix files in Power BI Desktop, may reuse an open session, closes Desktop if it opened it, never modifies the original file, and reports dropped items. This directly addresses side effects and performance implications, providing rich context beyond what the annotations convey.
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 every sentence serves a purpose: purpose, process, warnings, parameters, and output. It is well-structured into paragraphs and uses inline code for parameter names. It front-loads the main function and then details caveats and specifics without redundant filler.
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?
The description is quite complete for a complex tool: it explains the conversion process, the necessity of opening Desktop, behavior with open sessions, original-file preservation, required parameter conditions, and the output (warnings/dropped items). An output schema exists, so return values need not be spelled out. However, it does not cover all parameters (e.g., overwrite, desktop_timeout), which are relevant for a full understanding, leaving minor gaps.
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 schema description coverage at 0%, the description must compensate for parameter meanings. It explains key parameters like path (file or folder, recursive), out_dir (subfolder per report), include_model (skip Desktop), dataset_connection_string (required for live connections), and close_desktop (implicitly). However, it omits semantics for overwrite, project_name, request_id, and desktop_timeout, which are not self-explanatory despite their titles. The partial coverage leaves gaps.
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: 'Convierte uno o varios .pbix en proyectos .pbip (PBIR + TMDL).' It clearly defines the tool's purpose and differentiates it from sibling tools like pbi_create_pbip_project (which creates projects from scratch) and pbi_inspect_pbix (which inspects files).
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 provides clear context on when to use the tool: when you need to convert .pbix files into .pbip projects. It also notes conditional usage (e.g., include_model=false to skip Desktop processing, dataset_connection_string required for live connections). However, it does not explicitly mention alternatives or exclusions, such as when to prefer pbi_create_pbip_project over this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate non-read-only and non-idempotent. The description adds rich behavioral details: validation that the table exists and the measure doesn't (unless overwrite), the diff return, and the detailed constraints around mode ('both' disabled, Desktop open/closed requirements). This goes well beyond the annotation information.
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 well-structured and front-loaded with the main purpose. Each sentence adds value: validation, mode guidance, data_category example, and diff return. No filler or redundant text.
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?
Covers preconditions, mode selection, and return behavior, and the output schema handles structure. However, the incomplete explanation of several optional parameters creates some gaps for a 10-parameter tool.
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?
Schema coverage is 0%, so the description must compensate. It explains 'mode', 'data_category' with a concrete example, and 'overwrite' semantics. Required parameters (table, name, expression) are self-evident, but optional ones like format_string, display_folder, description, and request_id are not elaborated, leaving partial compensation.
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 clearly states 'Crea (o reemplaza con overwrite=true) una medida DAX', with a specific verb, resource, and the overwrite behavior. This distinguishes it from sibling tools like pbi_update_measure and pbi_create_calculated_column.
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?
Provides clear context on selecting mode ('live', 'pbip', 'auto') and when each is appropriate, including the 'construyendo desde cero' hint. However, it does not explicitly mention alternative tools or exclusions, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds meaningful behavior beyond that: it describes two specific return states (defined:false with clarifying questions, or the full brief plus recommended design system). This is useful context for an agent to know what to expect and how to handle the undefined case.
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 two short, focused paragraphs. The first sentence states the core purpose, and the second adds return behavior and usage timing. Every sentence contributes essential information without redundancy or filler.
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 a simple read tool with an output schema and annotations, this description is largely complete: it explains what it does, when to use it, and what it returns in both possible situations. The only gap is the unexplained request_id parameter, but given its optionality and the tool's simplicity, the overall context remains sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, request_id, is optional with a default empty string, but the description never mentions it. Schema description coverage is 0%, so the description must compensate but does not. An agent is left wondering what request_id refers to and whether it is needed to select the 'active project' or if it is merely a correlation ID.
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 starts with a specific verb+resource: 'Lee el brief de intencion del proyecto activo' (Reads the intent brief of the active project). It clearly distinguishes from siblings like pbi_define_brief (which would define rather than read) and pbi_apply_design_system (which applies rather than reads), while also mentioning it returns the recommended design system.
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?
It gives explicit when-to-use guidance: 'Consultalo ANTES de proponer paginas o elegir sistema' (Consult it BEFORE proposing pages or choosing a system), and explains the consequence of not doing so. This effectively communicates when it should be used versus relying on model inference, covering both the 'when' and an implied alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds valuable behavioral detail: it does NOT convert or open Power BI Desktop. This clarifies the tool's non-invasive nature beyond the annotations, but it does not discuss edge cases like invalid paths or file access issues.
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 a concise, three-sentence paragraph in Spanish that front-loads the core purpose and lists key outputs succinctly. Every sentence adds value, and the parameter explanation is cleanly separated at the end. No wasted words.
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?
The tool is a read-only inspection utility with a single parameter and an output schema (not shown). The description provides enough context about what the tool reports and when to use it, without needing to detail return structure. It could mention prerequisites (e.g., file existence) but overall is complete relative to its simplicity.
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 coverage is 0%, so the description must compensate for the single 'path' parameter. It provides a clear definition ('ruta al archivo .pbix') that adds context to the bare schema title, explaining the parameter's role as the target file path. While minimal, it is sufficient for a single simple parameter.
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 clearly states the tool inspects a .pbix file without converting or opening Power BI Desktop. It specifies exactly what information is provided (format, data model type, page/resource/custom visual counts), making it distinct from sibling conversion and listing 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 explicitly says it is for knowing what to expect before launching a conversion ('Sirve para saber que esperar antes de lanzar la conversion'). This gives clear usage context, but it does not name alternatives or explicitly state when not to use it, leaving a small gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
La descripción añade contexto de peso/rendimiento del DAX y el comportamiento por defecto de detail='full' por compatibilidad. Aunque readOnlyHint ya indica lectura, no contradice y aporta información útil sobre cómo evitar respuestas pesadas.
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?
Texto breve y bien estructurado: una frase de propósito seguida de recomendaciones claras y la explicación de tables. Cada oración aporta información útil, sin relleno.
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?
La herramienta es de complejidad media; la descripción cubre propósito, guía de uso, detalle de parámetros y recomendación de rendimiento. El output schema cubre el retorno. La omisión del parámetro 'source' es la única carencia notable.
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?
Explica los parámetros detail y tables en prosa, pero el tercer parámetro 'source' no se menciona. Con una cobertura de schema del 0%, la descripción compensa parcialmente pero deja un vacío claro.
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?
La descripción comienza con 'Lista medidas con tabla, expresion DAX, formato, descripcion y carpeta', verbo específico y recurso claro. Se distingue de siblings como pbi_get_object o pbi_search_model al mencionarlos explícitamente.
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?
Recomienda 'Empieza por detail=summary' y explica cuándo usar alternativas: 'para leer el DAX de una medida concreta usa pbi_get_object, y para buscar dentro del DAX, pbi_search_model'. También aclara el comportamiento por defecto de detail='full'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the safety profile is covered. The description adds behavioral detail by explaining the three resource categories and the real-world consequences of each mismatch (file not found, empty visual). This goes beyond the structured data and helps the agent understand what the tool surfaces and why.
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 two concise sentences plus a leading phrase. Every sentence provides meaningful information: what is listed, why the categories matter, and the fact that these issues are invisible. No wasted words, and the structure is easy to parse.
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?
Given the tool's simplicity (no parameters, read-only, with an output schema that presumably documents the return structure), the description covers the essential context. It explains the purpose, the three resource categories, and the significance of each mismatch. No obvious gaps remain for a list-type tool.
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?
The tool has zero parameters, and the input schema is empty. The baseline for no-parameter tools is 4 per the rubric. The description adds no parameter details because none are needed; it correctly focuses on the tool's output categories instead.
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 clearly states the tool lists report resources divided into three categories: declared, on disk, and mismatched. It uses a specific verb ('listar') and resource ('recursos del informe'), and distinguishes this tool from siblings like pbi_list_report_pages or pbi_list_visuals by focusing on resource-level inconsistencies.
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 why the tool is useful: to surface invisible issues where undeclared files or orphaned declarations cause problems. This implies when to use it (during audit or troubleshooting), though it does not explicitly mention alternatives or when not to use it. The context is clear enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true in annotations, the safety profile is already covered. The description adds behavioral context by specifying that it returns the model schema, visual catalog, and canvas/pages, and that it reveals available fields and visual types. It doesn't contradict the read-only annotation and provides useful information about the tool's output scope.
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 two sentences, both purposeful. The first enumerates the deliverables, the second gives precise usage timing. There is no redundant or filler content. It is fully front-loaded and easy to parse.
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 a tool with no parameters and an output schema, the description adequately covers purpose, content, and usage timing. It explains what the agent will get (model, visuals catalog, canvas/pages) and when to call it (before proposing a page). The output schema is available to fill in return structure details, so the description is sufficiently complete.
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?
The tool has zero parameters, so there is nothing to add beyond the schema. Per the rubric, 0 parameters earns a baseline of 4. The description doesn't need to describe parameter semantics, and it adds no irrelevant details.
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 clearly states the tool 'delivers the material for designing a page' and enumerates its contents: model (tables/measures/columns), catalog of existing visuals, canvas, and pages. It distinguishes itself from sibling tools by positioning itself as a pre-design resource that tells you what fields and visual types are available, not just listing individual tables or measures.
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 explicitly instructs to use this tool 'BEFORE proposing a page' and explains what it provides (fields and visual types). This gives clear contextual timing, though it doesn't name specific alternative tools or explicit when-not-to-use scenarios. The guidance is actionable and concise.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no meaningful annotations (all hints false), the description carries the burden. It explicitly discloses the key non-destructive behavior ('sin escribir nada al .pbip') and states the output is an HTML file path. It does not detail file cleanup or potential side effects of creating the HTML file, but the main behavioral trait is transparent.
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 two compact sentences with the key information front-loaded. Every phrase earns its place: the action, the non-destructive guarantee, the spec shape, and the output path. There is no wasted text.
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?
The tool is moderately complex (spec-driven HTML generation), and the output schema exists, so return values do not need elaboration. The description provides a sufficient input template and usage context. It could add more detail about required vs optional spec fields, but the provided structure is adequate for initial use.
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?
The schema only defines an opaque 'spec' object with additionalProperties and 0% description coverage. The description compensates by providing a concrete structure: {page_name, canvas?, layout?, visuals:[{type,title,fields,position?}]}. This gives meaningful guidance beyond the bare schema, though individual fields are not explained in depth.
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 clearly states the tool generates an HTML mockup of a proposed page ('Genera una MAQUETA HTML de una hoja propuesta') and explicitly distinguishes it from write operations by adding 'sin escribir nada al .pbip'. The verb, resource, and output are all specific, and it differentiates from siblings like pbi_create_page_from_spec and pbi_apply_page_spec.
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 implies when to use it: to review a proposed page design in the browser before committing anything to the .pbip file. It provides a clear workflow via the returned HTML path, though it does not explicitly name alternatives or state exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond annotations: the tool acts as a diagnostic-only mode without mapping, and it validates destinations before writing. This conditional behavior is not captured by the annotations, but the description does not elaborate on all side effects (e.g., dry_run behavior).
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 concise, front-loaded with the core purpose, and includes a practical example. Every sentence contributes useful information without unnecessary detail.
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?
The output schema covers return values, so the description only needs to clarify behavior. It explains the two modes, the validation step, and the mapping format. Minor gaps remain (e.g., dry_run semantics), but overall it is complete for the tool's complexity.
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?
The description provides an excellent example for the `mapping` parameter, clarifying its format and purpose. However, `dry_run` and `request_id` are not explained, and with 0% schema coverage, the description only partially compensates for the missing parameter documentation.
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 clearly states the tool's function: detect and repair broken references in visuals. It distinguishes two modes (diagnose vs. repair) and is specific about the resource and action, differentiating it from sibling tools like pbi_replace_visual_field.
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 explains when to use the tool: without `mapping` it only diagnoses, and with `mapping` it repairs after validating destinations. It also warns against guessing field mappings, providing clear guidance on responsible use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations by explaining that the visual applies the returned color as-is, and that valid field/target/visual combinations are validated server-side before writing. This is useful context that annotations (readOnlyHint=false) alone do not provide.
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 concise and well-structured: an introductory sentence, a clarifying analogy, and then bullet-style parameter explanations. Every sentence contributes value without unnecessary fluff.
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?
Given the tool's moderate complexity and the presence of an output schema, the description adequately covers the core behavior, parameter formats, and validation. It doesn't spell out prerequisites like needing an existing measure, but the intended pattern is clear enough for an agent to use it correctly.
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?
With 0% schema description coverage, the description compensates by detailing `field` (measures like '[Medida]' or 'Tabla[Medida]'), `target` (background, font, bars with visual-type context), and `target_column` (optional column to paint). It omits obvious params like page and visual_id, which are standard.
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 uses the specific verb 'Colorea' (colors) with a clear resource (a visual) and a precise mechanism (using a color returned by a measure). It distinguishes itself from sibling tools like pbi_set_conditional_format by explicitly identifying this as Power BI's 'valor de campo' mode.
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 gives clear context for when to use this tool: it's the typical pattern for a DAX-calculated traffic light. It does not explicitly name alternatives or say when not to use it, but the 'valor de campo' framing makes the intended use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide generic hints (all false), so the description carries the burden. It adds valuable behavioral context: hiding via `show=false` preserves text and format, and the old workaround left an unwanted band. This goes beyond the schema and annotations without contradicting them.
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 compact and front-loaded with the core purpose. It uses a short paragraph plus a bullet-like explanation of parameters. Every sentence adds value; there is no fluff or repetition.
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?
Given the tool's complexity (simple setter with nuanced hide behavior), the description covers the key aspects: operation, parameter combinations, and format preservation. It doesn't discuss errors or return values, but an output schema exists to handle return format. This is a complete enough description for an agent to use the tool correctly.
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 must compensate. It explains `title` and `show` in detail, including their interaction and the preservation behavior. It does not describe `page`, `visual_id`, or `request_id`, but those are self-evident from context and required fields, respectively.
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 clearly states the tool 'Cambia u oculta el titulo de un visual PRESERVANDO su formato' (changes or hides a visual's title while preserving its format). This specific verb+resource+behavior distinguishes it from siblings like pbi_set_visual_filter or pbi_update_visual_position.
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 the semantics of `title` and `show`, including when to pass one or both. It also explicitly contrasts with an alternative workaround (putting empty text) and explains why `show=false` is better. However, it doesn't compare against other visual-editing tools, so usage guidance is still somewhat implied rather than exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses rich behavioral details beyond annotations: Power Query step naming, real-file-signature detection for .xls, HTML table selection, culture inference, header-row autodetection, TMDL validation before commit, and the closed-project requirement. This goes far beyond the sparse 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 appropriately structured, starting with the main purpose and then covering edge cases using clear labels and bold emphasis. Each paragraph adds meaningful operational detail, though it could be tightened by moving less common edge cases into optional notes.
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?
The description is highly complete for a tool with complex file-handling behavior, covering formats, errors, validation, and dry-run output. It does not explain the overwrite parameter or table naming/description semantics, and it relies on the output schema for return-value details, which is acceptable but leaves minor gaps.
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 burden for parameter meaning. It effectively explains path, sheet, culture, dry_run, table_id, skip_rows, and format-related parameters. However, overwrite, table_name, description, and request_id are not described, leaving gaps.
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 clearly states the tool loads a file into the model with a specific verb and resource: 'Carga un archivo al modelo'. It distinguishes itself from sibling pbi_add_table_from_source by emphasizing file input support (.csv, .xlsx, .json, etc.) and the Power Query-like pipeline.
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 gives clear usage context: supported file types, required closed project, dry-run mode, and special handling for .xls/HTML files. It does not explicitly name alternatives like pbi_add_table_from_source, but the scope is well-defined enough to avoid confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds context: it is a structural and honest check, explicitly stating that key uniqueness/orphans are not checked when data are incomplete, and that the response communicates this via `not_checked`. It also reveals the output field `suggested_critical_fields`, providing behavior beyond the annotation.
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 structured into two clear mode-based paragraphs, with the main purpose front-loaded. It is somewhat dense but every sentence contributes meaning, referencing related tools and limitations without fluff.
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?
Given the two-mode complexity and the existence of an output schema, the description covers the main use cases, limitations, and integration with pbi_diagnose_data and pbi_define_brief. It does not explain `request_id`, which is a minor completeness gap, but overall it provides sufficient context for an agent to invoke the tool correctly.
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?
Schema coverage is 0%, so the description must explain parameters. It clarifies `source_path` as the mode selector and `dataset` as an add-on to `source_path`, but it does not mention `request_id` at all. This leaves one of three parameters undocumented, a notable gap.
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 clearly states it validates against the port contract, either an incoming file or the active model. It distinguishes itself from pbi_diagnose_data by explaining the different scope (pre-load structural checks vs. full data checks). The verb 'Valida' is specific and the resource is well-defined.
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?
It gives explicit usage conditions: with `source_path` (+ `dataset`) for pre-load file validation, without `source_path` for model validation. It also names an alternative (pbi_diagnose_data) for key uniqueness/orphans and the follow-up tool pbi_define_brief, forming a clear workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already signals a safe read operation, and the description adds behavioral detail by specifying that it lists tables and measures that exist only on one side and measures whose DAX differs. No contradictions with annotations; the description enriches the safety profile with specific comparison behavior.
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 two concise sentences. The first sentence states the core action, and the second explains the use case and what it outputs. There is no redundant or filler content.
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 no parameters, an output schema, and read-only annotations, the description covers the essential aspects: what is compared, what is listed, and when to use it. It is complete for its relatively simple scope and leaves no significant ambiguity about its behavior.
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?
The tool has zero parameters, so the baseline is 4. The description does not need to provide parameter semantics, and the schema covers 100% of parameters (none), making this adequate.
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 clearly states it compares the live model with the TMDL on disk, which is a specific verb+resource+comparison. It distinguishes itself from siblings by focusing on unsaved changes in memory versus the disk state, and explicitly mentions what it lists (tables, measures, DAX differences).
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 gives a clear use case: 'Util para saber si hay cambios en memoria sin guardar' (useful for knowing if there are unsaved changes in memory). It does not explicitly name alternatives or exclusion criteria, but the context of comparing live vs. disk is clear and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description adds significant behavioral context: it explicitly warns that the operation is destructive and requires confirm=true, clarifies that 'live' needs Desktop open while 'pbip' needs it closed, and explains the 'auto' fallback logic. This provides valuable operational detail not inferable from the annotations alone.
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 a single paragraph that front-loads the primary purpose and then explains mode behavior. It contains no filler, but the mode explanation is slightly verbose and could be tightened. It is reasonably concise and well-structured for the complexity involved.
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?
The description covers the key aspects needed to use the tool safely: destructive nature, confirm requirement, mode selection with prerequisites, and default behavior. With an output schema present to describe return values, the description is sufficiently complete. Minor gaps like error handling or missing-measure behavior are not critical.
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?
With 0% schema description coverage, the description compensates by explaining the 'mode' and 'confirm' parameters in detail, including the disabled 'both' option and the default behavior. The 'table' and 'name' parameters are not described, but their names are self-explanatory. 'request_id' is not explained, but it is a common internal field. The description adds enough value over the schema to earn a 4.
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 clearly states the tool's function with a specific verb and resource: 'Elimina una medida' (Deletes a measure). This distinguishes it from sibling tools like pbi_create_measure, pbi_update_measure, and pbi_rename_measure, which handle other operations on measures.
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 provides explicit guidance on when to use different values of the 'mode' parameter (live, pbip, auto), including the note that 'mode=both' is temporarily disabled and the default 'live' requires Power BI Desktop open. It also advises using 'auto' or 'pbip' when building from scratch. However, it does not mention alternatives like 'update measure' or when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description adds valuable context beyond that: confirm=true is mandatory, the tool refuses to delete the last page (with a rationale), and it updates page order and active page. 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 extremely concise: two sentences that front-load the core action and then provide essential safety caveats. Every sentence adds value, with no redundant wording.
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's simplicity and the presence of an output schema, the description covers all critical operational aspects: destructive nature, confirmation requirement, and the last-page guard. The agent has enough information to invoke the tool correctly without needing additional details.
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?
The schema has 0% description coverage, so the description must compensate. It does clarify that confirm must be true and implies page is the target. However, it does not explain the format of 'page' or the purpose of 'request_id', leaving some parameter ambiguity.
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 uses a specific verb ('Elimina una pagina') and resource ('pagina'), clearly identifying the delete action. It also mentions side effects (updating order and active page), which distinguishes it from sibling tools like pbi_duplicate_page, pbi_rename_page, and pbi_reorder_pages.
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 explicitly states that the tool is destructive and requires confirm=true, and it warns against deleting the last page. This provides clear usage guidance, though it does not name alternative tools. However, the deletion action is unique among siblings, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by explaining deterministic behavior, absence of heuristics, how skipped checks are reported, severity assignment for critical fields, and the requirement for a live open model. This adds substantial context not available from the readOnlyHint and openWorldHint 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 dense yet well-structured, starting with a clear purpose statement followed by a bulleted list of checks, then behavioral notes and prerequisites. Every sentence contributes value, with no redundant or filler content, and the front-loaded opening ensures quick comprehension.
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's complexity (four checks, skipped states, severity rules, prerequisites), the description is remarkably complete. It explains what each check does, how failures are categorized, the deterministic vs. subjective split, the skipped status semantics, and the model-open requirement. The output schema exists, so return values need not be described.
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?
The schema provides no descriptions for the two parameters (0% coverage), so the description must compensate. It explains the `tables` parameter's filtering semantics effectively ('narrows to relationships that touch those tables'), but it does not mention `request_id` at all. Thus, the compensation is partial, leaving one parameter completely unexplained.
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 clearly states a specific verb ('diagnose') and resource (data content against the live model), and enumerates the four deterministic checks. It distinguishes itself from metadata-only audit tools by explicitly targeting what 'breaks dashboards and no metadata sees', making it unique among siblings.
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 provides clear context for when to use this tool: to find data-level issues invisible to metadata, and it notes the prerequisite of an open model in Desktop. However, it does not explicitly contrast with alternatives like pbi_profile_data or pbi_analyze_model_quality, nor does it state when not to use it, stopping short of the 'explicit alternatives' benchmark.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true; the description reinforces this with 'Solo lectura' and adds behavioral context by enumerating the aspects it reports (dependencies, DLLs, session, project state) and that it flags issues like obsolete sessions and pending journals. 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 extremely concise—two sentences—and front-loaded with the core function ('Estado general del servidor'). Each sentence provides distinct value: the first defines scope, the second explains usage and expected outputs. No wasted words.
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 zero-parameter interface, existing output schema, and read-only annotation, the description fully captures the tool's role and the signals it reports. It tells the agent when to invoke it and what information it exposes, making it sufficient for selection and invocation.
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?
The tool has zero parameters, making schema coverage trivially 100%. There are no hidden parameters to document, so the baseline of 4 applies without any need for description compensation.
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 clearly states the tool's purpose: general server status (dependencies, DLLs, session, project) and checking whether the live layer is available and whether a .pbip project is open. It distinguishes itself from siblings like pbi_test_connection and pbi_session_info by positioning itself as the first diagnostic call.
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?
Explicitly states 'Es lo primero que conviene llamar' (it's the first thing to call), providing clear when-to-use context. It also lists what the tool checks (e.g., obsolete session, pending journals), but does not explicitly name alternatives or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to address mutation safety. It adds transparency by detailing what the tool returns—usage scenario, background color, series colors in order (with the rationale that order ensures color-blind-safe distinction), and status colors—which goes beyond the annotated safety profile.
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 concise, with the main point front-loaded and every sentence providing valuable information. It includes the purpose, the returned data, and usage guidance without any filler.
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 zero-parameter read-only listing tool with an output schema, the description thoroughly covers the purpose, output content, and usage context. The added detail about color order and accessibility makes it particularly complete.
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?
The tool has zero parameters, and schema coverage is 100% (vacuously). Per the rubric, the baseline for 0 parameters is 4, and the description does not need to add parameter semantics because there are none.
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 clearly states it lists available report themes with their palettes and purpose, using a specific verb and resource. It also distinguishes itself from theme application tools by emphasizing the use case of proposing a scheme before building.
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 explicitly instructs to use the tool to propose a scheme before building, and phrases it as an alternative to deciding for the user. However, it does not explicitly name sibling tools like pbi_apply_theme as alternatives, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is known to be safe. The description adds meaningful behavioral context: it classifies columns into status/date/metric families, returns complete pages with specs, and also discloses 'blockers' and 'themes' as part of the output. This goes beyond just the annotation.
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 well-structured and front-loaded with the core purpose, followed by differentiation and output details. It's slightly longer than the two-sentence ideal, but every sentence adds value—no fluff.
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?
The description covers the tool's purpose, how it differs from a key sibling, and what it returns (pages with specs, blockers, themes). Since an output schema exists, the description doesn't need to detail return structures. It doesn't mention prerequisites like model selection, but that's context likely handled elsewhere.
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?
The input schema has 0 parameters, so the baseline is 4. The description doesn't need to explain parameters since there are none, and it provides no parameter-specific information that could be added.
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 clearly states the tool's purpose: examine the model and propose several distinct dashboard designs with rationale. It explicitly differentiates from pbi_page_building_blocks, which only provides inventory, making the tool's role unambiguous.
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?
Explicit usage guidance is provided: use this tool to offer design options to the user instead of deciding for them. It contrasts directly with pbi_page_building_blocks, which leaves design decisions to the user, giving clear when-to-use signals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false), the description discloses detailed behavioral context: it compiles first, writes in a single transaction, updates the TMDL header, DAX expressions, and visual.json, returns a list of touched items, and warns about qualified references not being rewritten. This is rich, honest disclosure consistent with the annotation that it is a write operation without being destructive.
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 four dense sentences that cover the action, rationale, technical process, limitations, and prerequisites. It is front-loaded with the main verb and every sentence adds essential information without fluff.
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 complex rename-update tool, the description covers prerequisites (pbip only, Desktop closed), the transactional process, safety (dry_run default), output (list of touched items), and limitations (qualified references, warnings). Since an output schema exists, return values need no further explanation; this is complete enough for an agent to use correctly.
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?
Schema coverage is 0%, but the description compensates partially: it explains dry_run defaults to true and returns a plan without writing, and it contextualizes old_name/new_name via examples like `[old_name]` and `Tabla[old]`. However, it does not explicitly define table or request_id parameters, leaving some parameter semantics to inference.
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 'Renombra una medida actualizando TODO lo que la referencia', a specific verb (rename) and resource (measure) plus the key scope (updating all references). This clearly distinguishes it from sibling tools like pbi_update_measure or pbi_delete_measure, making the tool's unique purpose immediately evident.
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 states when to use it: for renaming measures safely instead of manually renaming, which would break visuals/measures silently. It also specifies a clear prerequisite: only works on .pbip projects and requires Desktop closed. However, it does not explicitly name alternative tools, so it falls short of a full when-to-use/when-not-to-use map.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful context beyond the readOnlyHint annotation by disclosing that it 'observes' the report and reports specific capabilities. It also explains the constraint that only existing visual types can be cloned, which is a behavioral trait relevant for the agent's planning. 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 extremely concise: two short sentences that front-load the key outputs and then provide the essential usage context. Every sentence earns its place with no redundancy or filler.
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 zero-parameter, read-only tool with an output schema, the description is complete. It explains what the tool provides, why it matters (the cloning constraint), and when to use it. The output schema handles return-value details, so no further explanation is needed.
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?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, but it does add value by describing the output (version, theme, custom visuals, clonable types), which complements the presence of an output schema.
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 clearly states what the tool does: it reports the observed PBIR version, theme, custom visuals, and clonable visual types. The verb is implied but specific ('dice cuales hay disponibles'), and the resource is 'el informe' (the report). This distinguishes it from sibling tools like pbi_list_visuals (lists actual visuals) and pbi_capabilities (generic capabilities) by focusing on the types available for cloning.
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 explicitly says to use this tool 'antes de intentarlo' (before trying) to create visuals, and explains why: only visuals of types already present in the report can be created. This gives a clear when-to-use context, though it does not name alternative tools or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the description need not repeat safety. It adds valuable behavioral context by explaining that the tool distinguishes valid vs stale vs mismatch sessions and reports freshness, which clarifies output semantics beyond the structured 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 two compact sentences, front-loaded with the core purpose and then adding the session-state distinction. Every clause earns its place; there is no redundancy or filler.
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 existence of an output schema and read-only annotations, the description is complete for a simple info tool. It conveys the essential output concepts (active model, project, freshness, status classes) without needing to enumerate return fields. The agent has sufficient context to use the tool correctly.
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?
The input schema has zero parameters with 100% coverage, so there are no parameter semantics to clarify. Baseline for zero parameters is 4, and the description appropriately focuses on the tool's output rather than nonexistent inputs.
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 clearly states the tool's function: it provides session details (active model, project, freshness) and distinguishes valid, stale, and mismatch session states. This specific scope differentiates it from generic health/connection checks, making the purpose unambiguous and non-tautological.
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 implies usage for verifying session status and validity, but does not explicitly name alternatives or exclusions. The context is clear enough for an agent to know when to invoke this tool, but it lacks explicit guidance on when to prefer it over sibling tools like pbi_health_check or pbi_test_connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool writes (unless dry_run=true), that the server decides geometry, that text color comes from the report theme (not the system), that the composition order is fixed for coherence, and that it warns if content doesn't fit. It also explains the dry_run behavior and that it follows the same validation/transaction as pbi_apply_page_spec. This goes far beyond the minimal annotations, which provide no read-only or idempotency guarantees.
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 well-organized with a clear introductory sentence, bullet-style explanations of each parameter, and a short rationale for design decisions. It is moderately long but every section adds value. The structure aids readability and front-loads the main purpose before diving into details.
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?
Given the tool's complexity (10 parameters) and the presence of an output schema, the description sufficiently covers the core behaviors and parameter semantics. It explains dry_run's return value and the fixed composition order, but doesn't describe the non-dry-run response in detail. However, the output schema likely fills that gap.
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?
Despite the 0% schema description coverage, the description thoroughly explains the meaning and expected structure of key parameters: title/subtitle, kpis, hero, supports, and detail, providing example JSON formats. It also describes dry_run's purpose. The only parameters not explicitly described are system, page_name, and request_id, but these are likely straightforward or auxiliary.
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 clearly states 'Compone una pagina entera sobre la rejilla del sistema de diseno' (composes an entire page on the design system grid) and explains the intention-driven approach. This distinguishes it from sibling tools like pbi_apply_page_spec (which applies an explicit spec) and pbi_create_page_from_spec (which creates from a specific spec), as it focuses on high-level page composition with automatic geometry.
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 conveys when to use this tool: when you want to compose a page by describing intention and letting the server decide geometry. It mentions dry_run for preview without writing and references pbi_apply_page_spec for validation/transaction path, but does not explicitly compare to alternatives 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavior beyond the read-only annotation by listing concrete issue categories and noting that 'Cada hallazgo trae su evidencia geometrica' (each finding includes geometric evidence). It also repeats the read-only hint but does not contradict 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 front-loaded with the core purpose in the first line, followed by a concise bullet-like list of detections and a one-line note about evidence. Every sentence earns its place with no filler.
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's single optional parameter, output schema, and read-only annotation, the description is complete: it states scope (one/all pages), what issues are found, and that findings include geometric evidence. No critical information is missing.
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?
With 0% schema coverage, the description fully compensates by explaining that the page parameter targets one page or all pages ('de una pagina (o de todas)'). The default null meaning is clear: omitting the parameter diagnoses all pages. This directly clarifies the only parameter.
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+resource: 'Diagnostica la geometria de una pagina' and enumerates exact layout issues detected (overlaps, off-canvas visuals, small sizes, margins, inconsistent spacing, Z-order problems, empty/saturated pages). This clearly differentiates it from sibling audit or documentation 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 phrase 'Diagnostica la geometria de una pagina (o de todas)' provides clear context for when to use this tool: to diagnose layout geometry on one or all pages. It does not explicitly state exclusions or name alternatives, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral detail beyond the readOnlyHint annotation: it does not open Desktop, examines each file, and reports whether each report would be copied (already in PBIR) or needs translation, and whether Desktop is required for model extraction. This is consistent with the annotation and clarifies the non-destructive preview nature.
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 tight and well-structured: a one-sentence summary, a brief behavioral explanation, and concise parameter documentation. No redundant or filler content.
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?
With an output schema present, the description adequately covers the tool's scope: it lists files, provides per-file conversion decisions, explains path/recursive semantics, and gives the preview context. It is sufficient for an agent to invoke correctly.
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%, but the description fully compensates by explaining `path` as a folder or a single .pbix file, and `recursive` as including subfolders. This provides clear semantic meaning beyond the bare schema.
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 clearly states the tool lists .pbix files in a folder and predicts conversion status for each, and explicitly calls itself 'la vista previa del lote' (the preview of the batch), distinguishing it from the conversion tool pbi_convert_pbix_to_pbip.
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 by describing this as the preview step before batch conversion and notes it runs 'sin abrirlos en Desktop' (without opening them in Desktop), implying usage for safe pre-conversion assessment. However, it does not name alternative tools or explicitly 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds behavioral context by enumerating what the summary includes and explaining the two source modes ('live' and 'pbip'). It does not contradict annotations and provides useful extra detail.
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 compact yet informative, with a clear opening phrase, a listed set of key contents, a usage recommendation, and a brief parameter explanation. Every sentence earns its place without unnecessary verbosity.
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?
The tool is a summary with one optional parameter, and an output schema exists, so return format doesn't need explanation. The description covers what the summary includes, when to use it, and how the source parameter works, making it complete for the tool's complexity.
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?
The schema has only one parameter with no description (0% coverage). The description fully explains the 'source' parameter, listing its possible values ('live' vs 'pbip') and their meanings, completely compensating for the schema gap.
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 clearly states the tool provides a compact model summary listing specific contents (counts, table sizes, measures per table, calculated columns, disconnected tables, bidirectional relationships, broken references). It also positions itself as the first tool to call for orientation, distinguishing it from detailed list tools like pbi_list_tables and pbi_list_measures.
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 explicitly says 'Es la primera tool que conviene llamar para orientarse en un modelo' (it is the first tool to call for orientation), which gives clear usage context. It does not mention alternatives or when not to use, but the recommendation is strong and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With destructiveHint=true and readOnlyHint=false, the description adds rich context well beyond the annotations: the XMLA credential-dialog limitation that causes infinite hangs, the timeout_seconds default/disable semantics, the 'ok with zero rows' gotcha, the warning list behavior, and the critical .pbip data-not-saved persistence fact. It also discloses the confirm=true requirement since 2.0.0. This is exactly the kind of behavioral disclosure a mutation tool with sparse annotations needs — no contradictions found.
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 substantial (~180 words across three paragraphs) but front-loaded with the core purpose and param summary before diving into edge cases. The timeout/credential paragraph, zero-rows caveat, and .pbip persistence note are all necessary behavioral disclosures. Only the historical note about 'the only destructiveHint tool without confirmation' is somewhat meta/trim-able, but it explains why confirm exists. Dense but every sentence earns its place.
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, credential-sensitive, hang-prone tool with 5 params, 0% schema coverage, and no enums, the description is remarkably complete: it covers type semantics, table selection, the critical timeout failure mode, return value semantics (status, duration, rows_by_table, refresh_timeout, warnings) even though an output schema exists, .pbip persistence behavior, and the confirm requirement. Nothing essential about successful use or failure modes is left unaddressed.
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 full burden, and it largely delivers: type's valid values (full | calculate | clear_values | automatic | data_only), tables's optional-omit-means-everything semantics, timeout_seconds's default (600), disable value (0), and hang-prevention rationale, and confirm's mandatory status. Only request_id is left undocumented, which is a modest gap given the otherwise thorough compensation.
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 opening sentence states the exact verb-resource-scope: refreshes the LOCAL model in Power BI Desktop, explicitly excluding the Service. This clearly distinguishes it from sibling pbi_open_and_refresh (which opens + refreshes), and the .pbip vs. model distinction further scopes its behavior. Purpose is unambiguous and differentiated.
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 gives explicit exclusion context ('not the Service' — so don't use it for cloud refresh) and references sibling pbi_open_and_refresh by name, implying when a different tool applies. It also explains important contextual behavior (confirm=true requirement, .pbip data-not-saved persistence) that informs when a refresh is meaningful. It stops short of a full when/when-not decision framework for all alternatives, but the local-vs-Service and refresh-vs-open-and-refresh contrasts are substantive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only set readOnlyHint=false, so the description carries the full burden. It explains side effects: opening Desktop, refreshing, closing if it opened, reusing session if already open, restoring model selection, and the data_loaded flag for capture representativeness. No contradictions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence carries meaning. It is structured into logical sections: purpose, capture method, parameter explanations, behavior on open/close. It front-loads the core purpose and then details nuances. Slightly verbose but not wasteful.
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?
Given the tool's complexity (9 parameters, .pbip nuances, side effects), the description is thorough. It covers the main use cases, edge cases (session reuse, data_loaded), and behavioral details. It does not explain the output schema in depth, but since output schema exists, that's acceptable.
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 has 0% description coverage, so the description fully compensates by explaining each parameter: path/pbip_path, page, refresh, fit_to_page, timeout, capture_timeout, refresh_timeout_seconds, and reuse_open. It also explains inter-parameter dependencies (e.g., refresh needed for .pbip data, page requires opening and refresh).
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 clearly states the tool's purpose: opens a .pbip/.pbix and captures its real window without relying on focus. It distinguishes itself from the PBIR validator by being the visual check that complements it, and from sibling tools like pbi_open_and_refresh by focusing on capture.
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 context for when to use the tool (visual check, complement to PBIR validator) and when to use refresh, page, and fit_to_page. It explains constraints like requiring the project not already open for page/fit_to_page, but does not explicitly exclude alternatives or say 'use X instead of Y'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral details beyond the readOnlyHint annotation: it explicitly states the dry-run mechanism (DEFINE MEASURE), notes that measures can reference each other, and describes the return structure (valid, sample value, error). This gives the agent a clear picture of what happens during execution.
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 concise (3 sentences) and front-loaded with the core purpose. Every sentence adds value: purpose, intended use, and parameter structure. No repetition or extraneous detail.
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's simplicity (one parameter) and the presence of annotations and output schema, the description provides all necessary context: what the tool does, how to format the input, and what the output will contain. An agent can invoke this tool correctly without additional information.
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?
The input schema only defines a generic array, leaving the inner structure undocumented. The description compensates fully by specifying that `measures` is a list of objects with `name`, `dax`, and optional `table` fields, and explains cross-referencing behavior. This is essential information that the schema lacks.
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 clearly states the tool validates DAX measures without modifying the model, using a dry-run with DEFINE MEASURE. It also specifies the intended use case (probing measures before creation), which distinguishes it from related tools like pbi_create_measure and pbi_run_dax.
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 explicitly says it is ideal for testing measures before creating them with pbi_create_measure, providing a clear usage context. It does not explicitly mention when not to use it or alternative validation tools, but the guidance is sufficient for an agent to select this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
This description goes far beyond the annotations (all false) by disclosing critical behavioral details: the credential workflow (first refresh must be completed by a human in Desktop), the fact that the table exists without data until then, that the server cannot verify the connection, and that TMDL requires a closed project. The transparency is exceptional and directly manages user expectations.
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 well-structured: a one-line purpose, bullet-like breakdown by source type, a bolded key requirement, and a clear warning about credentials. It is compact for the complexity involved, uses formatting (backticks, bold) to aid scanning, and every section earns its place without fluff.
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 tool with 14 parameters and no schema descriptions, this description is remarkably complete. It covers the main source types, parameter relationships, required fields, the credential caveat, and the TMDL dependency. Since an output schema exists, the lack of return-value explanation is acceptable. Only minor parameters like dry_run and overwrite are left undocumented, but the core behavior is fully covered.
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?
Despite the input schema having 0% description coverage, this description explains the meaning and constraints of many parameters: source values, server/database/schema/source_table/native_query for sql/postgres, odata URL pointing to entity set, web_json URL plus json_path, and the required columns array with its rationale. It does not cover dry_run, overwrite, request_id, or description, but the most operationally significant parameters are well documented.
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 clear, specific statement: 'Crea una tabla apuntando a una BASE DE DATOS o API externa.' It names the action (create table) and the resource (external database or API), and then details supported source types, distinguishing it from sibling tools like pbi_add_table_from_file.
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 provides clear context for when to use the tool: when adding a table from a database or API. It also gives important usage prerequisites, such as 'columns is mandatory' and the TMDL requirement that the project be closed in Desktop. It doesn't explicitly name alternative tools or when not to use it, but the source-specific breakdown effectively communicates the intended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description details the destructive consequences (unsaved changes lost, including refreshed data in .pbip), the required confirm=true, the verification of process identity, and the behavior when the file isn't open (does nothing, reports was_open: false). This adds substantial behavioral context that the annotation alone doesn't provide.
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 efficient and well-structured: starts with the core purpose, then provides context, behavior, and parameter nuances. Each sentence adds value without redundancy, making it both concise and informative.
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 that an output schema exists (not shown but indicated), the description covers all necessary aspects: purpose, usage context, destructive behavior, parameter meaning, and expected outcomes (verified_closed, was_open). It is complete for a tool of this complexity.
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?
With 0% schema description coverage, the description compensates by explaining the key parameters: path/pbip_path can be omitted to target the active project, and confirm must be true for destructive operation. It doesn't mention request_id, but that may be a generic parameter. The most critical parameters are well-documented.
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 clearly states the tool's function: closing the Power BI Desktop instance serving a specific project. It uses a specific verb ('Cierra') and resource ('instancia de Power BI Desktop que sirve ESE proyecto'), and distinguishes itself from sibling tools like pbi_open_in_desktop by focusing on the closing action.
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 provides strong contextual guidance: it explains that writing TMDL requires Desktop closed and that this tool fills the gap. It also mentions that the path can be omitted to close the active project. However, it does not explicitly name alternative tools or state when not to use it, though the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds meaningful behavioral details: it only works on the live layer, the TMDL reader will not return perspectives, and if none exist it returns an empty list with an explanation. This is useful context not available in annotations or schema.
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 extremely concise: three short sentences, each adding unique value (what it lists, the live-layer requirement, and the empty-list behavior). No redundant or filler content.
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 simple list tool with one optional parameter, an output schema, and read-only annotations, the description covers all critical context: purpose, operational constraint, and edge-case behavior. Nothing important 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?
The schema has one parameter ('source') with no description and 0% coverage, but the description's 'Requiere la capa EN VIVO' effectively tells the agent to use the 'live' source. This compensates for the lack of schema-level documentation, though it does not explicitly name the parameter.
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 starts with 'Lista las perspectivas del modelo', a specific verb ('lista') and resource ('perspectivas del modelo'). This clearly distinguishes it from sibling tools that list other model objects like tables, measures, or roles.
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 states when to use the tool: 'Requiere la capa EN VIVO' (requires the LIVE layer) and explains that the TMDL reader cannot extract perspectives. This gives clear context and a constraint, though it does not explicitly name alternative tools for other layers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing the failure behavior (window stays open if refresh fails, with desktop_left_open), the reuse_open option, and the destructive nature (discards unsaved memory data). It also warns about the confirm requirement. This aligns with destructiveHint=true and provides valuable context for the agent.
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 reasonably concise for the complexity it covers. It is well-structured with paragraphs, each addressing a distinct aspect (purpose, parameter alias, return behavior, failure handling, security requirement). Some redundancy exists (e.g., mentioning the two-call history in the first paragraph) but overall it earns its length.
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?
Given the tool's complexity (9 params, destructive, with output schema), the description is quite complete. It covers the operational workflow, failure handling, and key parameter relationships. It does not describe all parameters or the exact output format, but the presence of an output schema lessens that need. It effectively conveys the behavioral contract.
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?
With 0% schema coverage, the description must explain parameters. It clarifies that path and pbip_path are aliases, optional, and default to the active project. It mentions reuse_open and confirm effects. However, it does not explain type, tables, timeout, request_id, or refresh_timeout_seconds, leaving gaps for those parameters. Still, it covers the most critical ones.
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 clearly states the tool's purpose: 'Abre el proyecto en Power BI Desktop y lo refresca, en una llamada.' It names the specific verb (open and refresh) and the resource (Power BI Desktop project), and distinguishes itself from siblings like pbi_open_pbip_project and pbi_refresh_model by emphasizing the single-call combination.
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 provides explicit usage context: it calls out that opening without refreshing is useless for a .pbip with no data, explains that path/pbip_path can be omitted for the active project, and mentions that confirm=true is required since version 2.0.0. It also differentiates from separate calls by explaining the efficiency gain, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations false, the description carries the full transparency burden and does so well. It discloses waiting behavior, dynamic port identification, select=true behavior, reuse_open session reuse, that it never closes user windows, and the no-data caveat for newly opened .pbip files.
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 organized into short, purposeful paragraphs. It front-loads the main action, then adds workflow context, parameter notes, and a caveat. Every sentence contributes useful information without filler.
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's complexity and the absence of meaningful annotations, the description is remarkably complete. It covers the full workflow, side effects, parameter nuances, and next-step refresh guidance. The output schema handles return-value expectations, so no additional return description is needed.
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 must compensate. It explains path/pbip_path optionality and aliasing, select=true behavior, and reuse_open semantics. However, the timeout parameter is never explained, leaving one of five parameters without added meaning.
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 action: 'Abre un .pbip o .pbix en Power BI Desktop y espera a que sirva el modelo.' It clearly states the resource, the verb, and the expected outcome. It also distinguishes itself from siblings by emphasizing model-load verification and active-model selection.
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 gives clear context for when to use the tool: after editing a project, to verify it opens and to query measures without manual user effort. It also points to pbi_refresh_model as a follow-up when checking values. It does not explicitly list when-not-to-use or name alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation: it explicitly states 'No escribe nada' (writes nothing) and discloses that the tool returns the exact actions and reasons ('Devuelve las acciones exactas que se aplicarían, con su motivo'). This is valuable context not present in the structured 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 concise and well-structured. It front-loads the main purpose, then uses short, scannable sentences to convey constraints and parameter behavior. No unnecessary words; every sentence earns its place.
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?
The tool has an output schema, so detailed return-value explanation is not needed. The description covers the essential context: what it does, that it is read-only, and parameter semantics. It could have more explicitly stated when to use this tool versus pbi_apply_audit_fixes, but given the sibling context and output schema, it is reasonably complete.
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?
Even though schema description coverage is 0%, the description compensates by explaining both parameters: 'rules' must be explicit (aligning with the schema's required flag) and 'objects' narrows down further and provides IDs of visuals or pages. This adds meaningful semantics beyond the bare schema definitions.
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 clearly states the tool's function: 'Planifica correcciones para reglas CONCRETAS' (plan corrections for specific rules) and explicitly distinguishes it as a planning tool that does not write ('No escribe nada'). It also mentions returning exact actions to be applied, making the purpose specific and distinguishable from sibling tools like pbi_apply_audit_fixes.
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 provides clear usage context: it emphasizes that there is no 'fix everything' and that rules must be specified explicitly, which is a key guideline. It also notes that objects narrows down the scope. However, it does not explicitly name the alternative apply tool (pbi_apply_audit_fixes) for when to actually apply changes, though 'No escribe nada' implies the contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true; the description reinforces this with 'sin aplicar nada' and adds concrete behavioral details: the plan includes per-file diff and a state fingerprint, and applying becomes invalid if the project changes. This goes beyond the structured annotations and helps the agent predict 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?
Three short, information-dense sentences with no filler. The most important behavior (safe planning, token return) appears first.
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 an output schema and read-only annotation, the description adds the missing operational context: token semantics, diff/fingerprint contents, and rejection condition. It is sufficient for an agent to decide to invoke it and understand the result.
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 provides only names (`operation`, `arguments`) with no descriptions and 0% coverage. The description compensates by explaining that `operation` comes from `pbi_capabilities.planned_operations` and `arguments` are the same as the target tool would accept, giving the agent enough to construct valid inputs.
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 phrase 'Calcula un PLAN sin aplicar nada' (calculates a plan without applying anything) and names the return value `plan_token`. This clearly distinguishes it from sibling `pbi_apply_plan`, which actually applies plans.
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 states `operation` must be one of those listed by `pbi_capabilities` in `planned_operations`, and `arguments` are the same as the tool would accept. It also implies the typical workflow by explaining that `pbi_apply_plan` rejects the plan if the project changed. However, it does not explicitly state 'use this before applying changes' or list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, but the description adds substantial behavior: preview mode without confirm, the five possible states, rejection on changed files via `recovery_conflict`, the `force_conflict` override, byte-by-byte verification, and recreation of missing parent directories. It also reveals that conflicts prevent overwriting work, which is critical safety information.
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 compact, well-structured, and front-loaded with the core action and a warning. Every sentence adds value: preview behavior, conflict details, safety checks, and directory restoration. No filler or repetition.
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's destructive nature, the description covers all essential aspects: preview, execution, conflict resolution, verification, and side effects on parent directories. Since an output schema exists, return values are already structured. The description is complete enough for an agent to decide safely.
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 coverage is 0%, so the description must define parameter meaning. It clearly explains `confirm` (preview vs execution) and `force_conflict` (apply despite a conflict). `journal` is implicit in the tool purpose. However, `request_id` is not explained at all, leaving one parameter's semantics unclear.
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 starts with 'Restaura los originales guardados en un journal' — a specific verb and resource. It clearly distinguishes this tool from siblings like pbi_inspect_journal (inspect only) and pbi_purge_backups (permanently delete). The 'DESTRUCTIVA' marker reinforces its purpose as a recovery/restore operation.
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 explicitly explains the preview mode (without `confirm`) versus the actual recovery (with `confirm`), and how `force_conflict` handles conflicts. This gives clear context for when to use each parameter. However, it does not name alternative tools or state when not to use this tool, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses key behaviors: it rescales proportionally, bounds out-of-fit visuals, recalculates text colors, does NOT recompose, supports a dry-run mode that writes nothing, and writes to the report (PBIR). It explains the reasoning behind the 'no recompose' limitation. The annotations (readOnlyHint=false, destructiveHint=false) are consistent with the description; no contradiction.
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 well-structured and front-loaded with the main action. It uses three clear paragraphs: core functionality, limitation/alternative, and parameter notes. Every sentence contributes value, and the length is appropriate for the complexity described.
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 complexity (write operation with dry-run, out-of-bounds handling, color recalculation) and the presence of an output schema, the description is quite complete. It covers the why, what, limitations, parameter behavior, and operational requirement (project closed). The only minor omission is explicit documentation of `system`, but the context makes it inferable.
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?
Schema description coverage is 0%, so the description must compensate. It does explain `pages` (optional subset, default all) and `dry_run` (default true, returns plan without writing), which is helpful. However, the required `system` parameter is only indirectly referenced (as the destination system) but never explicitly tied to the parameter, and `request_id` is not mentioned at all. This partial coverage leaves meaning gaps.
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 clearly states the tool's function: 'Reescala las paginas ya escritas al lienzo de otro sistema.' It explains it rescales visuals and recalculates text colors, and explicitly contrasts with pbi_compose_page ('No recompone'), distinguishing it from siblings. The verb is specific and the scope is clear.
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 sets the context ('El camino de vuelta que faltaba'), explains when this tool is needed (after applying a system to composed pages), and provides an explicit alternative: 'Si una pagina necesita otra estructura, recomponla con pbi_compose_page.' It also mentions the prerequisite of having the project closed in Desktop, which is important usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by disclosing the fail-closed acceptance policy, the effects of max_rows, max_bytes, timeout_seconds, and export behavior, including writing to outputs/. It also reveals the response content (columns, truncation reasons, engine errors), providing thorough behavioral context.
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 front-loaded with the core purpose, followed by constraints, parameter semantics, and output behavior. Every sentence contributes useful information, and there is no filler or repetition.
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?
With an output schema present and annotations available, the description still adds critical context: accepted DAX forms, fail-closed policy, export side effects, truncation criteria, and error handling. It leaves no major gap for an agent deciding when and how to invoke this tool.
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 full burden. It explains export, max_rows, max_bytes, and timeout_seconds with their intended behavior. The 'query' parameter is only indirectly described as a DAX query, but the accepted forms section adds enough context to understand its purpose.
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 uses a specific verb ('Ejecuta') and identifies the resource ('consulta DAX contra el modelo activo'). It also enumerates the accepted query forms, making it clearly distinct from other tools that list static model metadata or perform audits.
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 explicitly defines when the tool may be used (read-only DAX queries) and gives clear exclusions (only EVALUATE, DEFINE...EVALUATE, and $SYSTEM DMVs; everything else is rejected with a fail-closed policy). It stops short of naming sibling alternatives, so it is not a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations false, the description carries the full burden and excels. It reveals file writes to StaticResources/RegisteredResources and report.json, the silent-ignore failure mode, deep-merge semantics for patch, loss of color-blind ordering when using data_colors, requirement for the project to be closed, and backup/replacement behavior. This is far beyond typical descriptions.
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 front-loaded with a one-sentence purpose, then organized by parameter with clear, dense explanations. Every sentence adds value, covering file paths, failure modes, merge semantics, and prerequisites, without wastefulness or repetition.
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 seven parameters, no required fields, and complex file-modifying behavior, the description covers all critical context: file operations, prerequisites, parameter interactions, replacement warnings, and backup recovery. An output schema exists, so return values are not needed. The only minor gap is the unexplained request_id, but it does not hinder effective use.
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 coverage is 0%, so the description must compensate. It thoroughly explains preset, data_colors, name, theme_json, fonts, and patch, including precedence and interaction (e.g., theme_json overrides preset; fonts and data_colors apply on top). The only omission is request_id, but that is a minor, likely common parameter, and the overall compensation is outstanding.
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 first line explicitly states the tool's core function: 'Aplica un tema de colores al informe .pbip activo' (Applies a color theme to the active .pbip report). It clearly names the resource type (.pbip report) and the action (apply theme), distinguishing it from sibling tools like pbi_list_themes and pbi_apply_design_system.
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 gives extensive guidance on parameter selection: use preset for presets, theme_json for full custom themes, fonts for typography, and patch for partial changes. However, it does not explicitly contrast with alternative tools such as pbi_apply_design_system, so it misses clear 'when to use this vs. that' tool-level guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already provide readOnlyHint=true, the description adds meaningful behavioral detail: it compares against current state, reports per-file status (original, backup availability, outcome), and reinforces that no restoration occurs. This goes well beyond the annotation by explaining the tool's analysis and output nature.
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 concise and front-loaded, with the primary action in the first sentence, followed by a short read-only note, then a summary of output, and finally the parameter explanation. Every sentence adds value, with no redundant 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?
Given the tool has only one parameter, an output schema, and annotations declaring read-only behavior, the description is complete. It covers the tool's purpose, safety profile, parameter source, and the kind of results produced. No additional context seems necessary for an agent to decide when and how to use it.
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?
The schema for 'journal' provides only type and required status with no description (0% coverage). The description compensates fully by explaining the parameter's meaning and origin: '`journal`: ruta devuelta por pbi_list_pending_journals'. This gives the agent the necessary context to correctly supply the value.
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 clearly states the tool's function: 'Inspecciona un journal y lo compara con el estado ACTUAL del proyecto' (inspects a journal and compares it with the current project state). It distinguishes itself from siblings like pbi_recover_from_journal by explicitly stating 'Solo lectura: no restaura nada' (read-only, restores nothing), making its purpose unique.
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 provides clear context by noting it is read-only and does not restore anything, implying it should be used for inspection rather than recovery. It also tells users where to obtain the journal parameter ('ruta devuelta por pbi_list_pending_journals'). However, it does not explicitly name alternative tools for restoration, so it lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses important behaviors: the full detail output can be extremely large (~28,000 chars for a small model), invalid table names cause an error that returns available tables, and the `source` parameter selects between live and pbip. This adds substantial value beyond structured 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 dense but every sentence adds value: purpose, parameter semantics, usage advice, and a warning about output size. It is well-structured with bold emphasis on the critical advice, making it easy to scan.
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?
With an output schema present and annotations provided, the description covers all necessary aspects: what is returned, how to control output size, and error behavior. The tool is simple enough that this description is fully sufficient for an agent to select and invoke it correctly.
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?
The schema has 0% description coverage, but the description thoroughly explains all three parameters: `source` (live vs pbip), `detail` (summary vs full with size implications), and `tables` (filtering and failure behavior). It fully compensates for the schema's lack of descriptions.
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 states 'Lista tablas con columnas, tipos, visibilidad y conteos' — a specific verb and resource, clearly distinguishing it from sibling tools that list measures, relationships, roles, etc. The title and description align perfectly, leaving no ambiguity about what the tool does.
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 gives clear usage guidance: start with `detail='summary'` to avoid context overload, then use `tables` to request details for specific tables. It does not explicitly name alternatives or exclusions, but the context and parameter guidance are highly actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which only indicate non-read-only and non-idempotent), the description discloses that applying a second gradient to the same property overwrites the previous rule ('dos degradados sobre la misma propiedad no se suman, se pisan'). It also explains the default behavior for missing min/max values and the requirement for target_column to be projected, adding valuable operational context.
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 well-structured: a short introductory sentence, a compact bullet-style explanation of each parameter, and a critical caveat about rule replacement. Every sentence contributes substantive information, and there is no redundant filler.
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 13-parameter tool with no schema descriptions and no annotation assistance, this description covers usage context, parameter semantics, and side effects thoroughly. The presence of an output schema means the description does not need to explain return values, making the content sufficiently complete for an agent to select and invoke the tool correctly.
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?
With 0% schema description coverage, the description compensates thoroughly by explaining nearly every meaningful parameter: field's table/measure syntax, target_column's role and prerequisite, target's possible values, mid_color's effect, numeric anchors, and null_strategy options. This is essential for correct invocation and far exceeds what the bare schema offers.
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 states 'Colorea un visual segun el valor de un campo (degradado)', which clearly identifies the tool as applying gradient-based conditional formatting. The analogies (heat map, traffic light scale) definitively clarify the purpose and distinguish it from other visual formatting tools like pbi_set_visual_title or pbi_set_color_from_field.
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 gives clear context: it is meant for gradient coloring based on field values and even warns that existing rules on the same target are replaced, which is critical for usage. However, it does not explicitly name alternatives for simpler static coloring or other formatting approaches, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds substantial behavioral detail: two validation layers (static lint and parser using the same serializer as Power BI), the exact shape of findings (rule, severity, file, line), the parse_checked=false edge case, and a list of data-dependent failures that the tool cannot catch. This goes far beyond the annotation and gives the agent an accurate model of what to expect.
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 compact yet information-dense. It front-loads the purpose, then systematically covers the two validation layers, output structure, limitations, and parameters. Every sentence contributes unique value, and the paragraph breaks guide the reader through the key concepts without unnecessary verbosity.
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's complexity (two-layer validation with multiple edge cases) and the existence of an output schema, the description covers all needed aspects: what the tool does, how results are structured, what it cannot detect, and parameter semantics. Limitations are explicitly documented, and the presence of an output schema means return values need not be spelled out in detail.
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?
The input schema has only minimal titles and defaults, with 0% schema description coverage. The description fully compensates by explaining that 'path' accepts a definition folder, a .SemanticModel folder, or a .pbip, and defaults to the active project, and that 'use_tom=False' runs only the static lint without touching DLLs. Both parameters are given clear, actionable semantics.
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: 'Comprueba si un modelo TMDL abrira, sin abrir Power BI Desktop' (Checks if a TMDL model will open, without opening Power BI Desktop). It distinguishes this tool from siblings by focusing on TMDL model validation and explicitly noting the no-Desktop requirement, making the purpose unmistakable.
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 provides clear context for use: validating TMDL models without opening Desktop, with path options (definition folder, .SemanticModel, .pbip) and a fallback to the active project. It describes the two-layer validation and limitations, but does not explicitly name alternative tools or state when not to use this tool, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the sparse annotations: it discloses that queries run 'en SOLO LECTURA,' that the tool refuses to export if the model is open but unprocessed, that dry_run returns DAX without touching the engine, and that each sheet declares applied and unapplied filters. This is rich behavioral disclosure and does not contradict 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: one-line purpose, then clear line breaks for select forms and behavioral details. Every sentence adds value; there is no filler or repetition. It is front-loaded and appropriately sized for the tool's complexity.
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 tool with nested select objects, 8 parameters, and an output schema, the description is remarkably complete. It covers what the tool exports, how to select content, execution modes, safety guarantees, output format, and sibling differentiation. An agent can correctly invoke it without additional clarification.
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 coverage is 0%, so the description bears full responsibility. It thoroughly explains the select parameter's three combinable forms, including pages, visuals, and queries with their sub-fields. It also explains format values, dry_run, and auto_open. However, it does not explicitly explain max_rows, max_rows_pdf, file_name, or title, though these are reasonably inferable from names/defaults.
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 clearly states the verb and object: 'Exporta el CONTENIDO del informe: los datos que muestra el tablero.' It also explicitly contrasts with pbi_export_excel and pbi_generate_pdf_report, which 'documentan el proyecto,' making the purpose unmistakable and distinct from siblings.
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?
It names the alternatives explicitly ('A diferencia de pbi_export_excel y pbi_generate_pdf_report') and explains what makes this tool different: it exports what the client sees. It also provides clear context for when to use it, including the live-model requirement and the dry_run/auto_open modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotions are all false, so the description carries full responsibility. It discloses side effects (replace vs merge, empty list removes all filters), failure modes (silently ignores invalid fields), and internal details (alias resolution). This goes far beyond what annotations offer, providing deep transparency without contradiction.
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 dense but structurally sound: a one-sentence summary, then clear sections for column vs measure specs, followed by critical behavioral caveats using bold formatting for emphasis. While long, every sentence adds value; it could be broken into more bullet-like lists but remains digestible given the tool's inherent complexity.
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 no schema descriptions and an output schema present, the description covers all essential aspects: input structures, edge cases (slicers, merge, silent failures), and usage context. It is complete for an agent to use the tool correctly and safely, addressing both typical and problematic scenarios.
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?
The schema has zero descriptions, but the description meticulously explains every aspect of the filters array—both column-based and measure-based specs, all conditions, optional fields, raw passthrough, and the merge parameter's default behavior. This transforms an opaque schema into a fully understandable API.
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 'Filtra un visual EXISTENTE sin escribir `filterConfig` a mano', which precisely identifies the action (filtering an existing visual) and the resource (visual), and differentiates it from manual configuration. The purpose is unmistakable and distinct from siblings like pbi_set_visual_title or pbi_set_visual_z_order.
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?
Provides explicit usage context: when to chain dimension slicers, when to use merge=true vs default, and the risk of erasing slicer selections (implicit when-not-to). It also contrasts with manually writing filterConfig, giving alternatives and conditions, satisfying the 'when/when-not' criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![horizun-pbi-mcp MCP server](https://glama.ai/mcp/servers/HorizunGroup/horizun-pbi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/HorizunGroup/horizun-pbi-mcp)

Score Badge

Copy to your README.md:

[![horizun-pbi-mcp MCP server](https://glama.ai/mcp/servers/HorizunGroup/horizun-pbi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/HorizunGroup/horizun-pbi-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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