Power BI Report MCP Server

Server Quality Checklist

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

Latest release: v0.9.6
Disambiguation4/5
Most tools have distinct purposes, but the sheer number (57) could cause some confusion, especially among formatting and bulk operation tools. However, each tool's description clearly differentiates its use case.
Naming Consistency4/5
Tools consistently use the 'pbir_' prefix and snake_case, with a predominant verb_noun pattern. Minor deviations like 'pbir_guide' and 'pbir_load_tools' are exceptions but still readable.
Tool Count3/5
57 tools is high for an MCP server, but the domain (Power BI report development) is complex and justifies many specialized operations. However, some tools could potentially be combined (e.g., multiple bulk operations).
Completeness4/5
The tool surface covers major aspects of report development: pages, visuals, formatting, filters, bookmarks, themes, and model cross-referencing. Missing data source management is acceptable as the server focuses on the report layer.
Average 3.9/5 across 57 of 57 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
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 description and annotations provide minimal behavioral details. No indication of how the grid is computed, whether existing positions are overridden, or what the output is. Annotations only have 'openWorldHint: false', which does not add behavior context.
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 overly brief (one sentence) and under-specified. While concise, it sacrifices necessary detail, making it less helpful. A short description should still capture key behavioral aspects.
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?
The description is incomplete given the tool's complexity and lack of output schema. It does not explain behavior like whether it affects all visuals or only those on the specified page, what the grid layout algorithm does, or what happens to existing margins. The sibling list shows many layout tools, but this one is not contextualized.
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 low (20%): only 'pageId' has a description. The tool description adds no parameter meaning beyond listing defaults. 'columns', 'padding', 'marginTop', 'marginLeft' are unexplained.
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 purpose: 'Auto-arrange all visuals on a page in a grid.' It uses a specific verb (arrange) and resource (visuals on a page), but does not differentiate from the similar sibling 'pbir_layout_grid'.
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 on when to use this tool versus alternatives. There is no mention of prerequisites, context, or excluded conditions. The one-sentence description provides no usage direction.
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 does not disclose behavioral traits such as side effects (e.g., triggering re-render), constraints on dimension values, or authorization needs. Annotations are minimal (openWorldHint: false), leaving the description to carry the burden, which it fails to do.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (6 words). While it avoids fluff, it is too brief to be informative, sacrificing completeness for brevity.
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?
Without an output schema, the description provides no information on return values or effects. Given the tool has 4 parameters (0 required) and involves visual changes, the description is insufficient for an agent to understand the tool's 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?
With only 25% schema description coverage (only pageId described), the description adds no extra meaning. It does not explain the purpose of width, height, or displayOption, nor units or allowed ranges.
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 'Update' and the resource 'page dimensions'. However, it lacks context about what kind of page (e.g., report page) and could be more specific to differentiate it from other page tools.
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 provided on when to use this tool versus alternatives like pbir_set_page_visibility or pbir_reorder_pages. No usage context or prerequisites 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?
Annotations indicate idempotentHint=true, and the description adds some behavioral detail (hex colors, dataColors 6-12, visualStyles keying). However, it does not disclose side effects, authorization needs, or what happens to existing theme settings. The description adds value beyond annotations but remains limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus fragments), which is concise but lacks structure. It front-loads the core action but omits important details. Could be improved with clearer separation of parameter constraints.
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 9 parameters, no output schema, and only idempotentHint annotation, the description is incomplete. It does not explain the 'name' parameter, return values, or the effect of other color parameters. A more detailed description is needed for effective tool 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?
With 0% schema description coverage, the description must add meaning. It provides some guidance for dataColors (6-12 values) and visualStyles (keyed by visualType or '*'), but ignores other parameters like name, background, foreground, etc. Partially compensates but insufficient for the 9-parameter schema.
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 states 'Apply a custom JSON theme' which is a clear verb+resource, but it is too vague to differentiate from siblings like pbir_apply_theme or pbir_set_report. It lacks specificity about what exactly the theme modifies.
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 (e.g., pbir_apply_theme, pbir_set_report). It does not mention prerequisites, context, or exclusion criteria.
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 does not go beyond stating the basic operation. No annotations (destructiveHint, readOnlyHint) are present, so the description carries full burden but provides no extra behavioral details (e.g., whether renaming affects references, if it is reversible).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence. It is concise but lacks important context. It is not overly verbose, but may be too terse for an agent to fully understand the operation.
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 simple rename operation with two parameters fully described in the schema, the description is minimally adequate. However, it does not mention the return behavior (e.g., no output schema) or edge cases (e.g., what happens if page not found).
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 100% description coverage for both parameters. The description adds no further meaning beyond the schema. 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 'Rename an existing page' clearly states the action and resource. It is specific enough to distinguish from sibling tools like 'pbir_rename_bookmark' or 'pbir_set_page_visibility', though it does not explicitly contrast them.
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 (e.g., pbir_create_page, pbir_duplicate_page). No prerequisites or context are mentioned.
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 does not disclose any behavioral traits beyond the basic action. Annotations only include 'openWorldHint: false', which does not add behavioral context. There is no mention of side effects, permissions, or error conditions, leaving the agent underinformed about what happens when reordering pages.
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 extremely concise, using a single sentence to convey the purpose. While it sacrifices detail, it is front-loaded and direct. It could benefit from slightly more context, but for a simple operation, the brevity is acceptable.
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 simplicity and full schema coverage, the description is minimally adequate. However, it lacks information about return values (none provided), error handling, or prerequisites (e.g., page IDs must exist). For a complete context, the description should at least hint at these aspects.
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 100% for 'pageOrder', and the schema adequately describes it as 'Array of page IDs in desired order'. The description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate as schema does the heavy lifting.
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 'Set the page order' uses a specific verb ('Set') and resource ('page order'), clearly indicating this tool reorders pages. It distinguishes from sibling tools like 'pbir_rename_page' or 'pbir_delete_page' which perform different operations. However, it is very brief and could be more descriptive.
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 or when not to use this tool. No alternatives are mentioned, and no context is provided about prerequisites (e.g., needing existing pages). The description lacks any usage direction beyond stating the action.
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 provide only openWorldHint: false, so the description must disclose behavioral traits. It states that the tool mutates (move/resize), but omits potential side effects like layout impacts, permission requirements, or whether coordinates are absolute/relative. This lacks sufficient behavioral detail 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, effectively communicating the core function without fluff. However, it could be slightly more structured by optionally adding usage tips without significant length increase.
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 7 parameters, low schema coverage, no output schema, and no annotations, the description fails to provide adequate context. It does not explain that only visualId is required, that pageId auto-resolves, or describe coordinate/unit systems, leaving significant gaps for correct tool use.
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 only 43% (only z, pageId, visualId have descriptions). The description adds no parameter-level details beyond the schema, failing to explain x/y units, width/height meaning, or z-order semantics. With low coverage and no compensation, the agent lacks essential 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 'Move and/or resize a visual on a page' clearly states the verb (move and/or resize) and resource (visual). It directly introduces the tool's functionality and distinguishes it from sibling tools like pbir_set_visual_title or pbir_delete_visual, which handle other aspects.
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?
No explicit guidance on when to use this tool versus alternatives. While the name and description imply it is for repositioning/resizing, there is no mention of prerequisites, exclusions, or comparisons to other visual manipulation tools, leaving the agent without clear contextual cues.
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 minimal (openWorldHint=false), so the description should disclose behavioral traits. It does not mention what happens if the bookmarkId is invalid, any side effects, or required permissions.
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, concise sentence. It is front-loaded and to the point, though it could be slightly more informative without losing conciseness.
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 simple rename operation, the description is minimally adequate. However, it lacks context about the tool's relationship to other bookmark tools and any constraints (e.g., bookmark must exist).
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 100% with descriptions for both parameters. The description adds no additional meaning beyond the schema, so baseline 3 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 clearly states the verb 'Rename' and the resource 'existing bookmark', making the purpose unambiguous. It distinguishes itself from siblings like pbir_add_bookmark and pbir_delete_bookmark.
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 (e.g., pbir_add_bookmark for creating), nor does it mention prerequisites or post-conditions.
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?
With only openWorldHint: false in annotations, the description adds value by specifying scope (all visuals on a page) and listing available themes. However, it does not disclose behavioral traits like overwrite behavior, undoability, or side effects, which would be expected 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 with no redundancy. The first sentence clearly states purpose, the second lists themes. Every word earns its place, making it easy to parse quickly.
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 lack of output schema and minimal annotations, the description should cover more aspects like what happens to existing formatting, how applyDataColors behaves, or prerequisites. It feels incomplete for a tool with three parameters and no return type.
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 only 33% (pageId has description). The description adds no further meaning for pageId or applyDataColors beyond the schema, and only repeats enum values for theme which is already defined. Since coverage is low, the description should compensate but does not.
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 (apply a named theme preset) and the scope (all visuals on a page), with an explicit list of theme options. This distinguishes it from sibling tools like pbir_set_report_theme which likely operate at the report level.
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 vs alternatives such as pbir_set_report_theme or pbir_lookup_theme_property. The description lacks context for selection, and there are no when-to-use or when-not-to-use indications.
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 lacks behavioral details such as side effects (e.g., overwriting existing formatting), idempotency, or reversibility. With no readOnlyHint or destructiveHint annotations, the description should disclose that this tool modifies report state. It only specifies parameter mappings, not overall behavior.
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 with two sentences, no wasted words. The first sentence clearly states the purpose, and the second adds critical parameter details. However, the structure could be slightly improved by grouping parameter explanations or using bullet points.
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 12 parameters and no output schema, the description only covers a fraction of the input space. Key parameters like rules, entity, pageId, colors, isMeasure, property2, and defaultColor are not explained, leaving the agent with incomplete context for correct 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 description adds value by explicitly mapping comparisonKind values (0=Eq, 1=GT, etc.) and listing formatType options, which are not fully detailed in the schema. This helps the agent understand parameter semantics beyond the schema's enum definitions. However, many parameters (e.g., rules, entity, colors) remain undocumented in 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 clearly states it applies conditional formatting to a visual container background or title font, which is distinct from sibling tools like pbir_format_visual or pbir_set_datapoint_colors. The verb 'apply' and resource 'conditional formatting' 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 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 (e.g., pbir_format_visual for simple formatting). There is no mention of prerequisites, context, or when not to use conditional formatting.
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 provide idempotentHint=true and openWorldHint=false, but the description adds no extra behavioral information (e.g., side effects, permission needs, interplay between color and wallpaper parameters). Safety profile is not expanded 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 single sentence is very concise, but it lacks structure (e.g., bullet points for parameters). Nevertheless, it efficiently conveys core purpose with minimal verbosity.
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 no output schema and 6 optional parameters, the description fails to integrate parameter details or explain what happens on execution (e.g., how clear interacts with color, return state). A more comprehensive description is needed for adequate contextual completeness.
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 supplements schema with a hex example (#0D1117) and transparency range (0-100), compensating for the 2 parameters lacking schema descriptions. However, it does not explain parameter interactions or default behavior.
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 'Set' and the resource 'page canvas background and/or wallpaper', specifying accepted value formats (hex color, transparency range). It also implicitly distinguishes from sibling tools since no other tool addresses background settings.
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 like pbir_apply_theme or pbir_set_report_theme, which also affect background. No when-not, prerequisites, or context for use.
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 already declare idempotentHint=true, but the description does not elaborate on idempotency, side effects, or return behavior. It merely states 'set or update' without mentioning that calling with only visualId might clear title settings or that changes are overwritten each call.
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 tight two sentences: first capturing the core action, second listing key capabilities. It is front-loaded with the verb and resource, and every phrase earns its place—no redundancy 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?
For an 8-parameter tool with no output schema, the description covers the main function but lacks context on required parameters (only visualId is required but not emphasized), auto-resolution of pageId, or behavior of partial calls. It is minimally complete but leaves gaps 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?
With only 38% schema description coverage, the description compensates partially by listing text, visibility, font, size, alignment—which map to parameters title, show, fontFamily, fontSize, alignment. However, it omits titleWrap and does not clarify the auto-resolution behavior of pageId noted 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 clearly states the verb (Set or update) and the resource (title of a visual), and lists specific properties (text, visibility, font, size, alignment). This distinguishes it from sibling tools like pbir_format_visual which handles broader formatting, and pbir_set_visual_sort which deals with sorting.
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 pbir_format_visual. It does not specify prerequisites, exclusions, or typical use cases, leaving the agent to infer context from the tool name and siblings.
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 mark the tool as destructive (destructiveHint=true). The description adds the condition for the confirmBulk parameter, which is a safety behavior. However, it does not disclose error handling or side effects when the condition is not met. The additional behavioral context is useful but not extensive.
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, no filler. Purpose is front-loaded, and the critical parameter guidance is included. Every word earns its place.
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 main action and key parameter constraint. However, it omits details like return value, error conditions, and the fact that pageId auto-resolves (though in schema). For a destructive bulk operation, more context (e.g., irreversibility) would improve completeness, but the essential info 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 coverage is 67%: pageId and confirmBulk have descriptions, visualIds lacks one. The tool description repeats the confirmBulk condition but does not clarify visualIds (e.g., format, source). It adds minimal value beyond 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 title and description clearly state 'Delete multiple visuals from a page,' which is a specific verb and resource. It is distinct from the sibling tool pbir_delete_visual, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to set confirmBulk (when >5), but does not explain when to choose this tool over alternatives like pbir_delete_visual or pbir_bulk_delete_visuals (though the name implies bulk use). No explicit when-not-to-use or alternative differentiation is given.
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 states it creates a page, clearly a mutation, but provides no additional behavioral context such as side effects, permissions, or limits (e.g., maximum pages, does it set active page). The description adds the three types, which is helpful, but overall it's minimal for a creation operation with no annotations about destructive hint.
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 concise sentence, front-loaded with the action and key information. No unnecessary words. Could potentially add more detail without being verbose, but it is efficient as is.
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 6 parameters, 1 required, and nested objects, the description is relatively brief. It does not mention the return value (no output schema), position of new page, activation behavior, or constraints like unique display name. However, the schema covers parameter descriptions comprehensively, so the description is minimally adequate.
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 has 100% description coverage, so the description's role is reduced. The description mentions 'standard, tooltip, and drillthrough page types', but the schema already describes the 'type' parameter and the 'drillthrough' object. The description does not add significant new meaning beyond what is in the schema.
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?
Clearly states 'Create a new page' and lists the supported types (standard, tooltip, drillthrough). This distinguishes it from other page manipulation tools like rename or delete. However, the phrase 'drillthrough page types' could be misinterpreted because drillthrough is not an enum value for the 'type' parameter but a separate property.
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?
No explicit when-to-use or when-not-to-use guidance. The description implies it is for creating pages of various types, but doesn't compare to alternatives like pbir_duplicate_page. The usage context is left implicit.
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 only states the basic operation. It does not disclose side effects, whether the duplication is deep or shallow, or any permissions required. Annotations are minimal (openWorldHint: false), so the description carries the burden, but fails to provide sufficient 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 a single, front-loaded sentence that conveys the essential information without any unnecessary words. Every part contributes to understanding the tool's purpose.
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 (5 parameters, no output schema) and the minimal description, there is a lack of completeness. The description does not explain default behavior, return values, or constraints like coordinate systems, which are important 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?
Schema coverage is 100%, with each parameter described. The description adds no additional meaning beyond what the schema already provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (duplicate) and resource (visual), with added specificity about optional repositioning and cross-page duplication. This distinguishes it from sibling tools like pbir_duplicate_page or pbir_move_visual.
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 provide explicit guidance on when to use this tool versus alternatives (e.g., move_visual or add_visual). The usage context is implied by the action, but no exclusions or prerequisites 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?
Annotations provide idempotentHint, so the description's minimal behavioral disclosure is acceptable. However, the description adds no extra context about side effects or limitations 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 a single sentence with no wasted words. It is appropriately sized for the tool's simplicity and front-loaded with the action and resource.
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 simplicity of the tool (two boolean parameters), the description partially covers the core functionality but fails to mention the 'expanded' parameter, leaving a gap in understanding the tool's full 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?
With 0% schema description coverage, the description should explain the parameters, but it does not mention 'visible' or 'expanded'. The agent must infer meaning from parameter names alone, which is insufficient for reliable 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?
Description explicitly states the action (show/hide) and the resource (filter pane), with a specific verb that clearly indicates the tool's purpose. It is distinct from sibling tools like pbir_list_filters or pbir_add_page_filter, which perform different operations.
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 on when to use this tool versus alternatives like pbir_list_filters or pbir_set_page_visibility. There is no mention of prerequisites, context, or conditions for showing/hiding the filter pane.
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 idempotentHint=true, but the description doesn't elaborate on behavioral traits like permissions, side effects on unspecified keys, or idempotency behavior. Listing keys adds some value but lacks depth.
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 sentence followed by a clear list of keys. No wasted words, front-loaded with purpose. Highly efficient.
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 has no output schema and one nested parameter, the description covers the keys well. However, it does not explain return values, error conditions, or permissions, leaving some gaps for a mutation 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?
With 0% schema coverage, the description compensates by listing the specific keys and their formats (e.g., exportDataMode with 0|1). This adds crucial meaning beyond the generic schema.
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 'Merge report-level settings' with a specific verb and resource, and lists the keys. It distinguishes from siblings like pbir_get_report_settings but could be more explicit about the set of settings being updated.
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 on when to use this tool vs alternatives like pbir_get_report_settings or other update tools. The sibling list is provided but no comparison or context for usage.
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?
Minimal disclosure beyond annotations. The annotation only provides openWorldHint=false, and the description adds no behavioral details such as side effects, placement of the new page, or whether filters/bookmarks are copied.
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?
Single sentence, concise and front-loaded with the key action and resource. No redundant information.
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?
Adequate for a simple tool with no output schema, but lacks details on new page positioning, default order, and what aspects of the original page are duplicated (e.g., filters, bookmarks).
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 100% schema description coverage, the schema already documents both parameters. The description adds no additional meaning beyond what is in the schema, resulting in baseline 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 ('duplicate an entire page with all its visuals') and the resource ('a new page'), distinguishing it from sibling tools like pbir_create_page (create blank page) and pbir_delete_page.
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 when to use this tool (copying a full page) but provides no explicit when-to-use or when-not-to-use guidance, nor compares it to alternatives like pbir_create_page or pbir_duplicate_visual.
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 idempotentHint=true and openWorldHint=false, so the tool understands it is an idempotent, known operation. The description adds that it sets the active page and that it is shown on open, but no further behavioral details (e.g., whether it throws errors if called with no pages or multiple 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?
A single, front-loaded sentence that conveys the essential purpose without any superfluous words. Every word earns its place.
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 simple tool with one optional parameter and no output schema, the description is adequate but minimal. It does not mention what happens when pageId is omitted (auto-resolved) or handle edge cases, relying on the schema for that detail.
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 100%, and the schema already documents the pageId parameter, including auto-resolution behavior. The description does not add additional meaning beyond 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 clearly states the verb 'Set' and the resource 'which page is active (shown on open)', distinguishing it from sibling tools like pbir_list_pages or pbir_create_page. It is specific about the tool's action.
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 on when to use this tool versus alternatives such as pbir_list_pages or pbir_set_page_visibility. The description does not provide usage 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 mark destructiveHint=true. The description adds the specific scope (page or visual) and the all-encompassing nature of the removal, providing moderate additional 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?
Single, concise sentence that immediately conveys the core action. No redundancy or filler; each 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?
For a simple destructive action with no output schema, the description adequately covers the tool's behavior. Minor omission: no mention of behavior when no filters exist or return value, but overall sufficient for correct usage.
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 100%, with both parameters already described in the schema. The description reiterates the same information without adding new meaning, earning baseline 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 ('Remove ALL filters') and the resource scope ('from a page or a specific visual'). It effectively distinguishes from sibling tools like pbir_remove_filter by emphasizing 'ALL' filters.
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 on when to use this tool versus alternatives like pbir_remove_filter. The description only explains what it does, without providing context for selection.
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 destructive behavior (destructiveHint: true). The description adds the important detail that all visuals on the page are also deleted, which provides useful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the essential action. It is front-loaded and wastes no words, though it could be slightly more informative without losing brevity.
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 simple destructive operation with one parameter and no output schema, the description covers the basic functionality. However, it lacks completeness regarding edge cases, such as effects on related bookmarks or filters, and does not mention any constraints.
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 100% and the single parameter 'pageId' is described as 'The page ID to delete' in the schema. The tool description adds no additional semantic information beyond what the schema already provides, so baseline 3 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 clearly states the tool deletes a page and its visuals, with a specific verb and resource that distinguishes it from sibling tools like pbir_duplicate_page or pbir_set_page_visibility.
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, e.g., whether deleting the active page is allowed or if there are prerequisites like no active visuals. The description lacks context for appropriate usage.
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 include destructiveHint=true, so the agent knows it's destructive. The description adds no further behavioral context (e.g., no mention of success state, error handling, or undo capability), but annotations already convey the key trait.
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 with no wasted words. It conveys the essential purpose efficiently.
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 one required parameter and a destructive annotation, the description is mostly adequate. However, it lacks mention of error conditions or return behavior (no output schema), and does not explicitly state irreversibility beyond the annotation.
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 100%, so the schema fully defines parameters. The description adds no additional meaning beyond what the schema provides, such as clarifying the auto-resolution of pageId or the format of visualId.
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 'Delete a visual from a page' clearly states the action (delete) and the resource (visual from a page), distinguishing it from siblings like pbir_bulk_delete_visuals (bulk delete) and pbir_delete_bookmark (delete bookmark).
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 (e.g., pbir_bulk_delete_visuals for multiple visuals), no prerequisites, and no mention of irreversibility beyond the annotation.
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 destructive behavior (destructiveHint: true). The description adds critical context: 'Empty file crashes PBI Desktop — tool auto-deletes when empty', which goes beyond annotations to warn about a serious side effect.
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 succinct sentences. First sentence states the purpose, second adds a crucial warning. No 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 description explains the core action and a critical edge case but omits details about return values and the specific operations (list/add/remove). Given 5 parameters, no output schema, and destructive hint, more context would be beneficial.
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?
Only 2 of 5 parameters have descriptions in the schema (dataType, expression). The description does not add any parameter-level guidance beyond what is already in the schema. The meaning of 'operation', 'tableName', and 'measureName' remains implicit.
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 manages extension measures (report-level DAX) in reportExtensions.json, with a specific verb 'manage' and resource. It distinguishes from sibling tools that deal with visuals, pages, etc.
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 on when to use this tool versus alternatives. While the purpose is clear, it does not mention when not to use it or provide context for selection among siblings.
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 destructiveHint annotation already indicates mutation; the description adds no new behavioral context beyond stating the action 'Remove'. It does not discuss permissions, reversibility, or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loading the action and scope. It is concise and well-structured with no unnecessary 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?
For a simple removal tool with no output schema, the description adequately covers the functionality. It could reference the origin of filter names (pbir_list_filters) but the schema already provides that context.
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 100%, so the parameter meanings are fully defined in the schema. The description adds no additional semantic value beyond what is already in the parameter 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 clearly states the tool removes a specific filter by name from a page or visual, providing a specific verb and resource. It distinguishes itself from sibling tools like pbir_clear_filters (which removes all filters) by specifying 'specific filter by name'.
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 when to use (when you need to remove a specific filter), but does not explicitly state when not to use or provide alternatives. Sibling tools like pbir_clear_filters offer contrasting functionality, but no direct comparison is given.
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 already indicate idempotency. The description does not disclose any additional behavioral traits like side effects, error handling if visuals do not exist, or the exact effect of 'NoFilter'. Minimal behavioral context beyond the core action.
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?
Extremely concise: a single sentence that directly conveys the tool's purpose and key parameter values. No extraneous information, perfectly front-loaded.
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 has 4 required parameters, no output schema, and moderate complexity, the description is somewhat adequate. It explains the core interaction but lacks details on constraints (e.g., pageId context, validation of parameters) and behavior of each interaction type. It is minimally viable but leaves 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 description adds meaning by explaining that the 'type' parameter selects among three interaction modes and that source and target are visuals in a directed relationship. This goes beyond the schema, which only provides enum values and basic property names. However, not all parameters are individually elaborated.
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 sets cross-filter interaction between visuals, specifying the exact action ('Set') and the possible values ('Filter/Highlight/NoFilter'). It distinguishes itself from sibling tools that deal with other visual properties or report configuration.
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 configuring how a source visual affects a target visual, but provides no explicit guidance on when to use it versus alternatives or any prerequisites (e.g., visuals must exist on the same page).
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 only include openWorldHint:false, but the description does not disclose potential side effects, reversibility, or error behavior (e.g., what happens if confirmBulk is false and count >5). The confirmBulk hint is more a usage guideline than 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 extremely concise (two sentences) with no wasted words. The first sentence states the core purpose, and the second adds essential parameter guidance. Front-loaded and effective.
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 has 5 parameters, 2 required, no output schema, and low schema coverage, the description covers key aspects: purpose, target modes, and confirmBulk requirement. It does not mention return values or error handling, but the schema covers the formatting structure. In context of sibling tools, 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 40% (descriptions for pageId, target, confirmBulk). The description adds semantics for target (container vs visual modes) and confirmBulk usage. However, it does not elaborate on visualIds or the formatting array structure beyond what the schema provides.
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 'Apply the same formatting to multiple visuals' and explains the two target modes (container for title/background/border, visual for axes/legend/labels), distinguishing it from sibling tools like pbir_format_visual which format a single visual.
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 guidance on when to use each target type and requires confirmBulk:true when applying to more than 5 visuals. It does not explicitly exclude alternative tools or scenarios, but the sibling list implies pbir_format_visual for single visuals.
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 indicate destructiveHint=true, so the description does not need to restate that. However, it adds no extra behavioral context beyond the basic action, like irreversibility or permission 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 a single, front-loaded sentence that efficiently conveys the core purpose with zero 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?
For a simple delete operation with no output schema, the description is sufficient. It identifies the required input and the action. Minor gaps like side effects do not significantly 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?
Schema description coverage is 100%, with the parameter already described as 'The bookmark ID to delete (from pbir_list_bookmarks)'. The tool description adds no additional semantic value beyond what the schema provides.
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 ('Delete') and the resource ('a bookmark') with the method ('by ID'). It uniquely identifies the operation among sibling tools like pbir_add_bookmark and pbir_rename_bookmark.
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 specifying the input (bookmark ID from pbir_list_bookmarks), but provides no explicit guidance on when to use this tool versus alternatives, such as renaming or listing bookmarks.
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 openWorldHint=false, so the agent knows it's a read-only operation. The description adds no further behavioral details beyond what annotations and output schema provide, which is adequate but not exemplary.
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, short sentence that efficiently conveys the purpose. It is well-structured and front-loaded, but could potentially add a note about the output without losing conciseness.
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, zero parameters, presence of annotations, and an output schema, the description provides complete contextual information. No missing elements are apparent.
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 correctly omits parameter details. The schema coverage is 100%, and the description does not need to compensate for missing parameter info. Baseline 4 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 the tool lists all bookmarks in the report, using a specific verb and resource. It distinguishes itself from sibling tools that add, rename, or delete bookmarks.
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 like pbir_add_bookmark or pbir_delete_bookmark. There is no mention of the context (e.g., enumerating bookmarks before modification) or any prerequisites.
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 provide minimal context (openWorldHint: false) and the description does not disclose any behavioral traits beyond the action. It fails to mention side effects, reversibility, or required permissions, which is insufficient 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 extremely concise with three short sentences that front-load the main purpose. Every sentence adds value with no superfluous 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 setter with 4 parameters and no output schema, the description covers the core functionality. It could be improved by noting that existing sort is replaced, but it 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 100%, so the baseline is 3. The description adds 'Use Table[Column] for field refs' which reinforces the schema but does not significantly enrich parameter understanding beyond the existing schema 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 clearly states 'Set the sort order of a visual' using a specific verb and resource, and distinguishes itself from sibling tools that modify other visual properties. It is 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 indicates the tool is used to override auto-sort, providing clear context. However, it does not explicitly state when not to use this tool or mention alternatives, though no direct sibling exists for sorting.
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 sparse (only `openWorldHint: false`), so the description carries the burden of behavioral disclosure. It mentions batch addition and inline formatting but does not explain key behaviors such as whether visuals are appended or replaced, idempotency, permissions, or error handling. The potential for destructive actions is not addressed.
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: four sentences with no wasted words. The first sentence front-loads the core action, followed by key features and specific examples. Every sentence adds 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?
Given the tool's complexity and the lack of an output schema, the description is adequate but incomplete. It covers main use cases but omits return value information (e.g., what IDs are returned) and behavioral details like duplicate handling or error conditions. The tool has many adjacent siblings, but the description does not fully differentiate them.
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 80%, so the schema already documents most parameters. The description adds value by explaining visual-type-specific bucket names (Series, Category) and directing users to `pbir_lookup_theme_property` for valid names. This semantic enrichment goes beyond 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 clearly states the tool adds visuals to a page in batch via the `visuals` array. It distinguishes from sibling tools like `pbir_format_visual` by noting that inline formatting avoids extra calls. Specific visual types (stacked charts, KPI card, scatter) are mentioned, making the purpose precise.
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 guidance on when to use this tool (batch add with inline formatting to avoid extra calls) and gives specific usage tips for different visual types (e.g., 'Stacked charts need a Series binding'). It also recommends using `pbir_lookup_theme_property` for valid names. However, it does not explicitly exclude 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it is a safe read operation. The description adds no further behavioral context (e.g., what happens to the report state, whether any side effects exist). With annotations covering safety, the description is adequate but not enriching.
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 short sentence that is front-loaded and contains no unnecessary words. It efficiently conveys the tool's purpose.
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 output schema and no parameters. The description is minimal: it states what is retrieved but does not explain the return format or any nuances (e.g., whether settings and theme are returned together or separately). Given the lack of output schema, the description should provide more detail for completeness.
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?
There are no parameters, so schema coverage is 100% trivially. The description does not need to explain parameters. Baseline score of 4 applies as no parameter information 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 verb 'Get' and the resource 'report-level settings and theme configuration', which distinguishes it from siblings like pbir_get_report_theme (which gets only theme) and pbir_update_report_settings (which updates settings).
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?
No explicit guidance on when to use this tool versus alternatives (e.g., pbir_get_report_theme for theme-only retrieval). The context of siblings implies differentiation but the description does not provide explicit when-to-use or when-not-to-use advice.
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 reveals a key behavioral detail: the bookmark is created with an empty exploration state, requiring manual capture in Power BI Desktop. This adds value beyond the annotations (which only have openWorldHint=false). For a creation tool, it offers reasonable 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 exceptionally concise: two sentences with no unnecessary words. The purpose is stated first, followed by a key behavioral note. It is well-structured and efficient.
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 (create bookmark with two parameters) and no output schema, the description covers the core functionality and important caveat (empty state). It could mention the required report context but overall is adequate.
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 100%, so the parameters are already well-documented in the schema. The description does not add any additional meaning or context about the parameters (displayName and activePageId), so it meets the baseline but does not exceed it.
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: 'Create a new bookmark.' It also adds context that the bookmark starts empty, which distinguishes it from other bookmark operations like renaming or deleting.
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 hints at usage by advising to use Power BI Desktop to capture the view state, but it does not explicitly state when to use this tool versus alternatives like pbir_list_bookmarks or pbir_rename_bookmark. No exclusion criteria or comparison to siblings is 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 are minimal (only openWorldHint=false), so the description carries the burden. It explains filter types and compound operators, adding context beyond the schema. However, it does not disclose side effects, permissions, error behavior, or what happens on duplicate filters.
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 with two sentences, no redundant information, and front-loads the main action. Every sentence adds essential guidance.
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 complexity (19 parameters, multiple filter types), the description covers key patterns and constraints. No output schema exists, but the tool's purpose is straightforward. It does not explain return values, but that is acceptable for an add 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 description coverage is 58%, and the description adds value by grouping parameters under filter types and explaining compound operators. However, many parameters (e.g., n, count, value) still rely on brief schema descriptions, and the description does not fully detail all parameter semantics for each filter type.
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 'Add a filter to a page or visual', using a specific verb and resource. It distinguishes between page-level and visual-level filters by mentioning omitting visualId, and lists filter types, making it 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 provides clear guidance on when to use which parameters (e.g., 'Omit visualId for page-level', 'topN requires visualId', and lists filter types with operator details). However, it does not explicitly compare to sibling tools like pbir_remove_filter, though the name implies addition.
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 reveals the primary behavior (changing visual type) and that data bindings are preserved, but does not disclose potential constraints (e.g., visual must exist, compatibility of visual types). Annotations provide no additional safety hints, so the description carries the burden; it is adequate but could be improved.
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 that immediately communicates the action and key feature (keeping data bindings). Every word is purposeful; there is no wasted text.
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 three required parameters, no output schema, and no nested objects, the description is fully sufficient. It covers the core function and the constraint, which is all that is needed 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?
Schema description coverage is 100%, so the baseline is 3. The description adds an example but does not provide additional meaning beyond the schema's built-in descriptions for the three 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 action (change visual type), the resource (existing visual), and the key constraint (keeping data bindings). The example further clarifies the input format. This distinguishes it from sibling tools like pbir_add_visual or pbir_format_visual.
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 by stating 'while keeping data bindings', but does not explicitly define when not to use or mention alternatives. Since the tool is unique among siblings, a score of 4 is appropriate.
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?
Description is consistent with readOnlyHint annotation (listing files). No additional behavioral traits disclosed (e.g., permissions, side effects). The folder path adds minor context but not beyond what annotations already suggest.
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?
Single sentence, no redundancy. Front-loaded with key information. Every word serves a purpose.
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 and a simple list operation, the description fully covers the tool's purpose. Output schema exists to explain return values, so no 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?
No parameters to document. Schema coverage is 100%. Description adds value by specifying the exact folder location for the theme files, which is not 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?
Description clearly states the action (list) and resource (theme files in StaticResources/RegisteredResources/ folder). This distinguishes it from sibling tools like pbir_get_report_theme or pbir_apply_theme.
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?
No explicit when-to-use or when-not-to-use guidance. However, the name and description imply it's for discovering available theme files, which is distinct from applying or modifying themes. Lacks alternatives 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?
Annotations are minimal (openWorldHint false). The description discloses the basic behavior (listing vs activating), but does not detail side effects of activation (e.g., persistence, permission requirements). Adequate 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?
Single, front-loaded sentence with zero wasted words. The two modes are clearly separated in a compact structure.
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 simplicity of the tool (one optional parameter, output schema exists), the description is complete. It covers both use cases without needing further elaboration on return values.
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 100%, so the schema already documents the parameter. The description clarifies the dual role (list vs activate), adding context beyond the schema. Baseline 3 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?
Clearly states two distinct purposes: listing on-demand tools (no arguments) or activating them by name (passing a 'tools' array). This distinguishes it from sibling tools which perform specific report manipulations.
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?
Explains when to use each mode: omit 'tools' to list, provide array to activate. However, no explicit when-not-to-use or alternatives are given, leaving some ambiguity about the scope of 'activate'.
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 explains the behavioral distinction between series and category charts, which is helpful. However, it does not disclose other behaviors such as whether colors are overwritten or additive, permissions needed, or side effects. Since annotations provide no additional behavioral hints, the description carries a moderate burden.
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—only two sentences—and front-loads the purpose. Every sentence provides essential information without 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?
For a tool with 6 parameters and no output schema, the description covers the core usage pattern but lacks details on error handling, return values, or edge cases (e.g., empty colors array). It is adequate but not comprehensive.
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 83% schema coverage, the schema already documents most parameters. The description adds value by clarifying the conditional requirement for categoryEntity and categoryProperty based on chart type, which is not obvious from the schema alone.
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: 'Set data point colors.' It distinguishes between series-based and category-based charts, specifying the required parameters for each, which differentiates 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 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 metadata mode (series-based) vs. categoryEntity+categoryProperty (category-based). It does not compare to alternatives or state when not to use the tool, but the context is 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 indicate idempotentHint=true, and description adds valuable context: 'Hidden pages still work for drillthrough.' This informs the agent about an important side effect beyond the toggle itself, enhancing 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?
Single sentence, no wasted words. Front-loaded with purpose, followed by crucial behavioral detail. Efficient and scannable.
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 boolean toggle tool with no output schema, the description covers the core action and the critical behavior (drillthrough still works). It is complete given the tool's complexity and the richness of annotations.
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 has 2 parameters with 50% description coverage (only pageId has a description). The tool description does not add new parameter details; hidden could benefit from explanation. Baseline 3 is appropriate as schema provides some info, but description misses opportunity to clarify.
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?
Description clearly specifies the verb (show/hide) and resource (page visibility in navigation pane). It distinguishes this tool from siblings by specifically mentioning navigation pane visibility and drillthrough behavior, which no other sibling covers.
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?
No explicit guidance on when to use this tool vs alternatives. The purpose is clear from context, but there's no mention of when not to use or comparison to similar tools like pbir_create_page or pbir_delete_page.
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 include openWorldHint: false, which is not contradicted by the description. The description adds context about switching reports but does not disclose additional behavioral traits such as whether it requires specific permissions or what happens to current state. Given minimal annotations, this is adequate but not exceptional.
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, front-loaded with the key action, and contains no unnecessary words. Every sentence serves a clear purpose.
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 tool with one parameter and no output schema, the description gives enough context: what the tool does, when to use it, and what input is expected. No additional details are needed.
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 100% with the 'path' parameter fully described in the schema. The description repeats the path requirement but adds no new semantic details beyond what the schema provides, so baseline score of 3 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 clearly states the tool's purpose: 'Connect to a different Power BI report'. It specifies the resource type (.Report folder or .pbip project) and distinguishes itself from siblings like pbir_get_report by indicating it switches reports mid-session.
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 usage guidance: 'Use this to switch reports mid-session without restarting the server.' It gives a clear context but does not mention when not to use it or alternatives, though the use case is well-defined.
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 annotations: it specifies the output format (summary header + topN findings) and the behavior of the topN parameter (0 = all). No contradiction with annotations (readOnlyHint true).
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 efficiently convey purpose and key parameter behavior. Zero 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?
Given the presence of an output schema and comprehensive parameter descriptions in the schema, the description covers the essential aspects. Minor gap: does not mention that the audit is per page or that it requires a pageId, but that is clear from the 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 coverage is 100%, so the description's extra detail on topN (default 20, 0 = all) adds marginal value. It does not explain the verbose parameter beyond 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 clearly states the action ('Audit'), the resource ('visuals on a page'), and the specific aspect ('theme overrides'). It distinguishes itself from sibling tools that handle other operations like setting visibility or applying themes.
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 checking theme compliance on a page, but does not explicitly mention when to use this tool versus alternatives. However, given the readOnlyHint annotation, it is safe to use without side effects.
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 adds the behavioral detail that slim mode returns Table[Column] strings, which is helpful. 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 extremely concise at two sentences, with no unnecessary words. It front-loads the main purpose and then adds key detail about slim mode.
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, the description does not need to explain return values. It covers the purpose and slim mode behavior. However, it could briefly mention what happens when pageId/visualId are omitted or error cases.
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 high (67%), but the description adds value for the `slim` parameter which is undocumented in the schema. It explains the default behavior and output format, compensating for 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 clearly states it lists filters on a page or visual, distinguishing itself from sibling filter tools like pbir_add_page_filter. It specifies the slim mode output format, making the purpose very 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 does not explicitly state when to use this tool versus alternatives, or when to use slim vs full mode. It provides implicit context but lacks explicit guidance on usage 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?
Description reveals 'Replaces the query state entirely' – a key behavioral trait beyond annotations. Also mentions validation behavior with strictBindings. Adds clarity about the tool's effect.
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 with no wasted words. First sentence states purpose, second clarifies replacement behavior, third illustrates shorthand. Efficient and well-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?
Covers main aspects: update bindings, replacement behavior, shorthand syntax. No output schema, but return values not critical. Could mention prerequisite (visual must exist) but implicit. Complete given 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?
Description explains shorthand 'Table[Column]' notation and provides an example, adding value beyond the schema's field descriptions. Schema coverage is high (80%), but the description compensates for the remaining 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?
Description clearly states 'Update the data bindings of an existing visual' – specific verb and resource. Distinguishes from other visual manipulation tools like pbir_add_visual or pbir_change_visual_type by specifying data bindings.
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?
Description does not explicitly state when to use this tool vs alternatives (e.g., for changing visual type use pbir_change_visual_type). Usage context 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?
Discloses that bindings are replaced and that continueOnError validates per-entry, adding value beyond the sparse annotations. 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?
Two sentences with front-loaded purpose; each sentence adds essential guidance without 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?
Covers main usage and key parameters, but lacks information about return values or error handling, which would improve completeness.
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?
Adds contextual guidance beyond the schema's parameter descriptions (e.g., when confirmBulk is required), though schema coverage is already high.
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?
States 'Rebind multiple visuals in one call' with specific verb and resource, and distinguishes from sibling tool for single visual updates.
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 context for when to use (bulk operation) and explicit guidance on confirmBulk and continueOnError, but does not explicitly exclude single visual case.
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 mark readOnlyHint=true. The description adds valuable behavioral context: default returns a summary, verbose returns full raw PBIR JSON. No contradictions.
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 purpose, minimal waste. Every sentence adds value.
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 output schema exists, the description adequately covers default and verbose output. No missing information for a read tool with rich schema and annotations.
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 100%, so baseline 3. The description adds meaning by stating 'slim' is deprecated alias for '!verbose', and explains verbose effect beyond schema. Provides useful nuance.
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 'Get visual details' clearly states the action and resource, with specific details on default output and the verbose option, distinguishing it from listing or mutation 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?
No explicit guidance on when to use this tool versus alternatives like pbir_list_visuals for listing all visuals or other getters. The context implies it's for reading a single visual, but lacks explicit when-not or alternative references.
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?
Disclosures beyond annotations: totalVisualCount sums full set, slim behavior, and the effect of pageId. No contradictions with readOnlyHint.
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?
Single, well-organized paragraph with no filler. Could benefit from bullet points but remains clear and efficient.
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 key behaviors and parameters sufficiently. Output schema exists so return format need not be described. Lacks mention of offset/limit pagination behavior, but parameter constraints are in schema.
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?
Adds context to slim, includeVisuals, and pageId beyond schema descriptions. Explains totalVisualCount and cross-page recommendation. Limit/offset not elaborated but schema provides defaults and limits.
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?
Clearly states the tool lists pages with pagination. Distinguishes from sibling page tools by specifying functionality and parameter effects.
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 guidance on when to use includeVisuals:true vs. per-page calls, and explains totalVisualCount behavior. However, does not explicitly list when to avoid using this tool.
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?
Discloses that the theme file is kept but unlinked, adding context beyond the destructiveHint annotation. No contradictions.
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, no wasted words. First sentence states core action, second provides important side effect. Efficient and well-structured.
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 tool with annotations, the description fully covers the effect and side effect. No output schema needed as return is likely void/success.
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?
No parameters; schema coverage is 100% by absence. Description adds no parameter information but none is needed. Baseline 4 for zero-parameter 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?
Clear verb+resource: 'Remove the custom theme from the report, reverting to the default base theme.' It distinctly describes the action and distinguishes it from sibling tools like pbir_set_report_theme or pbir_get_report_theme.
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?
Implies usage when removing a custom theme, but no explicit guidance on when to use versus alternatives (e.g., pbir_set_report_theme for changing theme), nor any conditions or exclusions.
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 reinforces this with 'Read-only.' It adds behavioral context by detailing what the tool checks (margins, gaps, etc.) and what it returns (errors, warnings, stats), 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 extremely concise: two sentences plus a short phrase. It front-loads the core purpose and specifics in the first sentence, then adds output details and pairing suggestion in the second. No extraneous 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 tool has only 2 parameters (0 required), full schema coverage, and an output schema, the description sufficiently covers what validation is performed, what output to expect, and how to combine with a sibling tool. No gaps remain.
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 100%, so the schema already documents both parameters adequately. The description echoes the scope options and auto-resolution behavior but does not add additional semantic meaning beyond the schema. Baseline score of 3 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 clearly states the tool validates layout against wireframe rules, listing specific checks (margins, gaps, overlap, etc.) and output types (errors, warnings, stats). It distinguishes itself from the sibling pbir_audit_theme_compliance by suggesting pairing, 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 explicitly marks the tool as read-only and recommends pairing with pbir_audit_theme_compliance for full verification. However, it does not provide explicit 'when not to use' or alternative tools, but the context is clear enough for an agent.
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. The description adds transparency about live discovery from skills/*.md files, informing the agent that topics are dynamically sourced. No destructive behavior is implied, and there is 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 purpose and immediately provide actionable usage. Every sentence earns its place 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 tool's simplicity (single parameter, no output schema), the description covers the essential aspects: domain, live discovery, and listing capability. It is complete enough for the agent to understand how to invoke it, though it could optionally mention the expected response format.
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 already describes the 'topic' parameter with a description. The tool description adds the crucial usage example of passing 'list' to enumerate topics, which goes beyond the schema's definition and enhances 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 defines the tool as providing domain knowledge for Power BI report development, with a specific mention of live discovery from skills/*.md files. This distinguishes it from sibling tools which focus on specific actions like setting page visibility or renaming 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 provides explicit guidance on how to list available topics using topic:'list', which aids in initial discovery. However, it does not explicitly state when not to use this tool, relying on contrasting sibling tool 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 (readOnlyHint=true) indicate no destructive side effects. Description adds that it generates an HTML dashboard, a non-obvious behavioral detail. No contradictions. Could mention that it modifies nothing, but safe assumption given readOnlyHint.
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 succinctly describes outputs, second provides prerequisite and recommended prior call. Every sentence serves a purpose 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?
Covers purpose, prerequisites, parameter behavior, and output type (HTML dashboard). Slightly lacking on where the dashboard is saved or how to access it, but given the output schema existence, this is acceptable.
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 100% with detailed descriptions for both parameters. The description adds no further semantic value beyond what the schema already provides, so baseline 3 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?
Description clearly states the tool cross-references the semantic model with the report, showing measure/column usage, DAX dependencies, unused fields, and per-page coverage. It also mentions generating an HTML dashboard. This distinguishes it from siblings, which focus on page, visual, or theme manipulation.
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?
Explicitly states the prerequisite of a sibling .SemanticModel/ folder and instructs to call pbir_get_report first to check hasSemanticModel. This provides clear when-to-use guidance and an alternative path if the condition is not met.
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 reinforces this by stating it returns a diff without side effects. It adds value by explaining the output structure (added, removed, changed) beyond what annotations 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 two concise sentences that front-load the action and output, wasting no 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 tool has an output schema (implied), the description adequately conveys the input and output semantics. The sibling tools provide context for usage, and no additional details are 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 coverage is 100% for the single parameter 'theme'. The description explains the parameter's purpose in context (comparing against current theme and producing a diff), which adds meaning beyond the schema's 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?
Description clearly states the tool compares a proposed theme JSON against the current theme and returns additions, removals, and changes. It distinguishes itself from sibling tools like pbir_apply_theme by emphasizing previewing before applying.
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 notes the tool is 'useful for previewing theme changes before applying,' giving clear context for when to use it. However, it does not explicitly mention when not to use it or list alternatives like pbir_apply_theme.
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 description adds value by specifying the return format (base theme name + custom theme JSON), going 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?
Single sentence with no wasted words, front-loaded with the key action and output description.
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 getter with no parameters and an output schema present, the description is fully adequate—covering purpose, output, and conditions.
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?
No parameters exist, so schema coverage is 100%. Baseline score of 4 applies as per guidelines for 0-parameter 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?
Description clearly states 'Get the currently applied theme' with specific verb and resource, and distinguishes from sibling tools like pbir_apply_theme and pbir_set_report_theme which are write operations.
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 reading the current theme, but lacks explicit when-not-to-use or alternatives. The context from sibling names provides differentiation.
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 details beyond the readOnlyHint annotation, explaining the progressive query pattern and that propertyFilter is a case-insensitive substring filter. It does not, however, describe error handling or output format (which is covered by the output 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 two sentences and highly efficient, using semicolons and plus signs to concisely convey the drill-down pattern. Every part earns its place with no wasted words, 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 that the tool is a simple lookup with optional parameters and an output schema exists, the description completely covers the needed usage context. It explains the progressive query logic, which is sufficient 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?
The input schema already describes each parameter individually (100% coverage). The description adds value by explaining how parameters combine: visualType then category, with propertyFilter as a filter. This hierarchical usage meaningfully extends what the schema provides.
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: to query the Power BI theme schema for valid visualStyles property names. It explains the hierarchical navigation (visual types → categories → properties), which distinguishes it from sibling tools that perform actions like applying themes or modifying visuals.
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 showing the drill-down pattern: no arguments lists visual types, adding visualType lists categories, etc. It provides clear context on how to use the tool but does not explicitly state when not to use it or mention alternatives, though no direct siblings compete.
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 details beyond the sparse annotations: server handles margin/gap math, planOnly mode behavior, and reserveBannerRow effect. No contradictions.
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 with zero waste. Front-loaded with purpose, followed by usage guidance and key behavioral 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?
Given the complexity (11 params, nested objects, no output schema), the description covers core behavior and usage. However, it lacks details about the return format of the plan, which is a minor 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?
Schema coverage is 82%, so most parameters are documented. The description adds value by summarizing planOnly behavior and referencing guide('wireframes'), though it doesn't explain each parameter individually.
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 computes a deterministic grid and positions cells, and distinguishes it from N pbir_add_visual calls. It also explains the planOnly mode.
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?
Explicitly says 'Use this INSTEAD of N pbir_add_visual calls when building a page from scratch.' It also differentiates when to use planOnly:true vs false, providing clear context.
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?
Discloses auto-routing logic and gotchas, which adds behavioral context beyond annotations. However, it does not explicitly state nondestructive nature or permissions, though inferences are clear.
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 front-load the purpose and routing logic, then add important gotchas. No wasted words; each sentence is 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 the tool's complexity (routing, gotchas), the description covers all key usage aspects: routing behavior, override mechanism, reference to lookup tool, and visual-specific caveats. Output schema is absent but not required.
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 100% schema coverage, the description adds significant value by explaining routing details, override options, and specific property examples, exceeding the baseline of 3.
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 formats visual properties, with specific auto-routing behavior and override options. It distinguishes itself from sibling tools like pbir_set_visual_title and pbir_bulk_update_format.
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 guidance on when to use auto-routing vs overrides, references pbir_lookup_theme_property for valid names, and highlights important gotchas for slicer and waterfall visuals.
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 repeat that. It adds transparency by revealing the tool returns a boolean indicating the existence of a `.SemanticModel/` folder, which is useful behavioral context. A slightly richer output description could improve, but it's already good.
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 only two sentences, front-loading the purpose, then providing an output detail and a usage hint. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, an existing output schema (per context), and annotations covering read-only, the description adds critical context about the `hasSemanticModel` flag and its relation to a sibling tool, making the tool fully self-explanatory for an agent.
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?
There are no parameters, so schema coverage is trivially 100%. The description has no parameter info to add, and per rubric, 0 parameters with full coverage warrants a baseline of 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 shows the currently connected report path and includes the `hasSemanticModel` boolean. This distinguishes it from sibling tools which manipulate visuals, pages, or other aspects.
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 advises to check `hasSemanticModel` before calling `pbir_model_usage`, providing a concrete when-to-use and when-not-to-use guideline. This is direct 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?
Annotations already mark it as read-only. The description adds valuable behavioral details: default returns a slim list (~150 tokens), verbose returns detailed metadata (~1,200 tokens). No contradictions.
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, no fluff. The main purpose is front-loaded, and each sentence adds distinct value.
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 read-only list tool with one optional boolean parameter and no output schema, the description fully explains the behavior and output variants.
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 covers the verbose parameter's description, but the description adds meaning by specifying default vs verbose output formats and token sizes, aiding the agent in deciding which mode to 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 states 'List available visual types' which is a clear verb+resource. It distinguishes from siblings like pbir_list_visuals (which lists visuals in a report) by focusing on types, not instances.
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 when to use the default vs verbose mode, providing context on token consumption. However, it does not explicitly state when to choose this tool over alternatives, though it's the only tool for listing visual types.
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 clearly warns that unsaved work is lost, even adding detail about modeling-MCP measures not flushed by autosave. Annotations already mark destructiveHint: true, so the description significantly adds 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the core action then adding crucial safety and usage details. Every sentence earns its place with 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 only one parameter, no output schema, and annotations providing destructiveHint, the description is fully complete. It covers purpose, usage, safety, and parameter behavior adequately.
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 100% for the single parameter. The description adds value by explaining the semantic difference between confirm=true (execution) and false/omitted (warning), which is not fully captured in the schema's 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 clearly states the tool reloads a report by closing and reopening the .pbip file. It distinguishes itself from sibling tools by explicitly mentioning it closes PBIDesktop.exe, which is unique among the listed 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 explains that confirm=true is required to proceed, and when false/omitted it returns a save-first warning. It provides clear context for use but does not explicitly state when not to use it or list alternatives beyond the save-first flow.
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 indicate readOnlyHint=true and openWorldHint=false. The description adds valuable behavioral details: pagination, slim response fields, filterCount inclusion, and auto-resolution of pageId when one page exists. No contradictions.
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 appropriately sized with five concise sentences, each adding essential information. The purpose is front-loaded, and every sentence earns its place without redundancy.
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 (5 parameters, pagination, filtering), the description fully covers usage scenarios and integration with other tools. The output schema handles return value details, so the description does not need to repeat them.
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 80% schema description coverage, the description adds significant value: it explains slim behavior beyond the schema, reiterates and contextualizes limit/offset, describes pageId auto-resolution, and details visualType filtering before pagination affecting total 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 lists visuals on a page and is paginated. It uses a specific verb-resource combination and distinguishes itself from sibling tools like 'pbir_get_visual' (single visual) and 'pbir_add_visual' by focusing on listing and pagination.
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 guidance on pagination with limit/offset, filtering by visualType, and combining with 'pbir_list_pages' for cross-page sweeps. It also explains the slim parameter behavior, offering clear usage context and alternatives.
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:

[![powerbi-report-mcp MCP server](https://glama.ai/mcp/servers/jonathan-pap/powerbi-report-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jonathan-pap/powerbi-report-mcp)

Score Badge

Copy to your README.md:

[![powerbi-report-mcp MCP server](https://glama.ai/mcp/servers/jonathan-pap/powerbi-report-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jonathan-pap/powerbi-report-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/jonathan-pap/powerbi-report-mcp'

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