Horizun PBI MCP
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation3/5
Many tools have clear scopes, but the page spec family contains overlapping members like pbi_create_page_from_spec vs pbi_apply_page_spec and pbi_preview_spec_html vs pbi_preview_page_spec. Additionally, pbi_document_model and pbi_generate_technical_documentation both produce documentation, creating potential misselection.
Naming Consistency5/5All tools follow a consistent pbi_ prefix with lowercase snake_case, and the vast majority use a verb_noun pattern (list_, create_, update_, delete_, etc.). A few noun-only names such as pbi_capabilities and pbi_health_check are minor deviations but do not break the overall predictability.
Tool Count1/5With 90 tools, this is far beyond the 25+ threshold, and even exceeds the 50+ extreme mismatch criterion. The sheer number makes selection difficult and suggests the server is trying to cover too many granular operations.
Completeness4/5The toolset provides extensive coverage across model management, DAX execution, auditing, report layout, page generation, and backup/recovery. Minor gaps exist, such as no direct create/delete table or column operations, but these are workaroundable.
Average 3.9/5 across 90 of 90 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto 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?
No annotations are provided, and the description fails to disclose whether this tool modifies existing pages, requires specific model context, or has side effects. It only describes the page composition (KPIs and chart), leaving behavioral expectations unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no waste. However, it is under-specified; while efficient in length, it lacks the richness needed for a tool with multiple parameters and implied behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 1 required) and lack of annotations, the description is far too sparse. It does not mention the purpose, prerequisites, or the meaning of key parameters, making it insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description needed to explain parameters like seed, dry_run, category, and measures. It only hints that measures are used for KPIs, but leaves the other parameters completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this tool creates an executive summary page containing a row of KPIs and a hero chart. Combined with the tool name 'pbi_build_executive_page', the purpose is evident. It does not explicitly differentiate from siblings like pbi_build_evm_page, but the specific page type sets it apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as pbi_build_evm_page or pbi_generate_report_page. The description only implies its use for executive summaries but does not state conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a determinism guarantee ('Determinista: la misma entrada produce siempre la misma salida'), which is a useful behavioral note. However, with no annotations at all, it fails to disclose that this tool likely mutates visual positions, whether it overwrites existing alignment, impacts z-order, or requires visuals on the same page. This is insufficient for a layout-changing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main action, and uses a clear inline list for edge values. There is no redundancy, filler, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value details are not required. But the description omits critical operational context: what alignment actually does to the visuals, prerequisites, how it interacts with other layout tools, and error behavior. For a mutation tool with no annotations, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description carries the full burden. It does explain the 'edge' parameter with its allowable values (left, top, etc.), which is the most complex parameter. However, it does not describe 'page', 'visual_ids', or 'request_id' at all, leaving the agent to guess their roles despite their self-explanatory names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Alinea varios visuales por un borde' (align several visuals by an edge). It specifies the resource (visuals) and the operation (aligning), and even lists the possible edges. However, it does not explicitly distinguish itself from sibling tools like pbi_arrange_visuals or pbi_distribute_visuals, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as pbi_arrange_visuals (arrange visuals), pbi_distribute_visuals (distribute visuals), or pbi_normalize_page_layout. It merely states what it does without providing selection criteria or exclusions.
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?
No annotations are provided, so the description must carry the full burden. It only states the primary effect without disclosing side effects, whether changes are applied immediately to the report, permission requirements, or how z-order interacts. This 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded, but given the tool has 8 parameters and no other context, it is under-specified. It earns its place but more content is needed to be adequately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is incomplete. It fails to mention coordinate system, whether it modifies the live report or PBIP project, the role of z, and any prerequisites or limitations. Significant gaps remain for a tool with multiple parameters and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema descriptions, the description should compensate. It implies x/y are coordinates and width/height are dimensions, but does not clarify units, coordinate system, the meaning of the optional z parameter, or request_id. Parameters like z and request_id remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mueve/redimensiona un visual existente' clearly states the action (move/resize) and the resource (existing visual), distinguishing it from create/delete/title-set tools. It is 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/5Does 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 other layout tools like align, distribute, or normalize. It neither states explicit use cases nor excludes alternatives.
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 absent, so the description carries the full burden. It discloses no behavioral traits such as side effects, safety, or the meaning of the 'source' parameter. The listing action is implicitly safe but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the core purpose without any wasted words or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the presence of an output schema covers return values. However, the unexplained 'source' parameter and lack of usage guidance leave notable gaps, making the description barely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not mention the 'source' parameter at all. Its meaning, possible values, and effect remain completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as listing partitions per table, including storage mode and origin. This specific verb and resource distinguish it from sibling list tools like pbi_list_tables and pbi_list_measures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what the tool does without context, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not explicitly disclose whether the operation is read-only, requires special permissions, or has any side effects. It relies on the verb 'list' to imply safety but does not confirm it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence that directly states the tool's function without superfluous words, achieving high conciseness for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the purpose is clear, the description omits any explanation of the 'source' parameter and does not provide usage context or behavioral details. The presence of an output schema mitigates the need for return format, but the missing parameter semantics and usage guidance make it incomplete for a complex environment with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes a 'source' parameter with a default of 'live', but the description does not explain its purpose or possible values. Since schema description coverage is 0%, the description fails to add meaning to this parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista los roles de seguridad (RLS) y sus filtros por tabla' clearly identifies the action (list) and the resource (security roles/RLS filters), distinguishing it from sibling tools that list other model objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives like pbi_list_tables or pbi_audit_model. The description only states the function, leaving usage entirely implied.
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?
With no annotations provided, the description carries the full burden. It discloses what the tool lists but does not mention whether it is read-only, whether it operates on the currently selected model, or any potential side effects. The parameter 'source' is not addressed, leaving behavioral assumptions ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the primary action and resource. All words contribute meaning, with no redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is an output schema, the description lacks essential context for a tool with an undocumented parameter. It does not explain the 'source' option, nor does it provide any guidance on model selection or prerequisites. The minimal description is insufficient for an agent to correctly invoke the tool, especially given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter ('source') with 0% description coverage, and the tool description does not mention this parameter at all. The description adds no meaning beyond the bare schema, failing to compensate for the low coverage. This leaves the agent without guidance on what 'source' represents or how to set it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Lists the hierarchies of the model with their levels and columns.' It uses a specific verb ('list') and resource ('hierarchies'), and the inclusion of 'levels and columns' clarifies the output scope. This distinguishes it from sibling tools like pbi_list_tables or pbi_list_measures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its explicit focus on hierarchies, but it does not explicitly state when to use this tool versus alternatives or mention any prerequisites. It lacks direct comparison to sibling tools or contextual clues beyond the name itself.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It lists what is checked but does not state whether the tool is read-only, what it returns (beyond detection), whether it modifies anything, or what the output format looks like. The output schema exists but is not visible to the agent from the description alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The first sentence states the purpose, and the second lists concrete examples. Every sentence provides useful information without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and the types of checks performed, which is adequate for a simple analysis tool. However, missing parameter semantics and lack of behavioral details (e.g., read-only, return behavior) leave gaps in selecting and invoking the tool correctly. The output schema likely covers return values, but this is not referenced in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, 'source', with a default of 'live' and 0% description coverage. The description does not mention this parameter at all, leaving its meaning, possible values, and impact undocumented. Since schema coverage is low, the description fails to compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Detecta problemas tipicos del modelo (calidad)' and enumerates specific checks (measures without folders, long DAX, bidirectional/inactive relationships, calculated columns, visible IDs, missing calendar). This specific verb+resource combination distinguishes it from sibling tools like pbi_audit_model or pbi_health_check by focusing on model quality patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case ('revisa...') but does not explicitly state when to use this tool over alternatives, nor does it mention prerequisites or exclusions. It is clear from context that it is for analyzing model quality, but no when-not-to-use guidance is provided.
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?
There are no annotations, and the description does not mention side effects, reversibility, or return behavior. It does not warn that rearranging visuals may overwrite existing positions or require specific permissions. The only behavioral info is the default for visual_ids (all) and the custom map structure, which is parametric, not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the main purpose in the first sentence and parameter details in compact code-formatted lines. Zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no annotations, and a mutation operation, the description is incomplete. It doesn't explain the return value (despite an output schema being present), doesn't state whether the tool modifies the report directly, and doesn't cover all parameters. It is minimally sufficient for simple cases but lacks depth for safe autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains meaning for layout (valid values), visual_ids (optional subset, default all), and custom (map format for custom layout). However, with 0% schema description coverage, it fails to explain canvas, spacing, and request_id, leaving these ambiguous. It adds some value but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Reorganiza los visuales de una pagina' (reorganizes the visuals of a page), which is a specific verb+resource. The mention of layout presets (grid, dashboard, executive_summary, custom) helps distinguish it from sibling tools like pbi_align_visuals and pbi_distribute_visuals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like pbi_align_visuals, pbi_distribute_visuals, or pbi_normalize_page_layout. The description only explains parameters, not selection criteria.
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 no annotations, the description discloses the registration side effect and the separation of measure creation. It does not mention permissions, error conditions, or whether existing visuals are affected, leaving gaps for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. It includes a useful note about measure creation and the DAX approach, without unnecessary filler, though it could be slightly better structured with parameter explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 the tool's specific nature, the description covers the core behavior and workflow. However, it omits parameter details and alternative guidance, making it moderately complete but not fully self-sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains html_measure by stating it expects a measure returning HTML, but other parameters (page, title, position, request_id) are not described, leaving most parameters without added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates an 'HTML Content' visual that renders HTML/SVG from a measure. This is specific and differentiates it from generic visual creation tools, though it does not explicitly name siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions that the measure is created separately with pbi_create_measure and that the visual is registered if not already present, providing some workflow context. However, it lacks explicit guidance on when to use this tool versus alternatives like pbi_create_visual.
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?
No annotations are provided, so the description must carry the burden of behavioral disclosure. 'Exporta' suggests a read-only operation, but the description does not state side effects, return behavior, or whether any model/page context is required. The output content (layout + fields) is mentioned, but this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the tool's purpose and includes clarifying parenthetical detail. Every word earns its place; there is no redundancy or unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description gives the core purpose and output nature (HTML skeleton with layout and fields). However, it omits usage context, parameter format, and any behavioral caveats, leaving it minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'page' with 0% description coverage, so the description must compensate. It only indicates the page must already exist, which adds a constraint, but it does not explain the expected identifier format, how to specify the page, or any examples. This is thin semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Exporta') and a precise resource ('MAQUETA HTML de una pagina EXISTENTE'), further clarified by the parenthetical '(layout + campos de cada visual)'. This clearly distinguishes the tool from sibling tools that generate, preview, or create page specs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the page must be 'EXISTENTE', implying this is for existing pages rather than new ones, but it gives no explicit when-to-use guidance and does not mention alternatives or exclusions. Sibling tools like pbi_generate_page_spec or pbi_preview_page_spec are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses important behavior: it validates suggested fields and explicitly does not invent fields, creates cards and charts, applies an indicated layout, and returns a summary. It does not mention side effects like overwriting existing pages or required permissions, but the creation behavior is clearly described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and every sentence adds value. It communicates the core action, the validation constraint, the visual composition, the layout handling, and the return type without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a clear high-level workflow and mentions a returned summary, and an output schema exists. However, for a tool with 6 parameters, no parameter explanations, no annotations, and many sibling page-building tools, the description lacks key input semantics and usage context, making it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not compensate. It only indirectly references 'layout' and 'campos sugeridos', but does not explain page_name, objective, request_id, available_fields_hint, or create_missing_measures. Most parameters remain semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it generates a report page with suggested visuals from the model and describes the concrete steps (reviews the model, validates suggested fields, adds measure cards and one chart per category, applies the layout, returns a summary). It is specific about the verb and resource, but does not explicitly differentiate itself from sibling tools like pbi_generate_page_spec or pbi_build_dashboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The phrase 'a partir del modelo' implies a use case, but it does not mention when to prefer pbi_generate_page_spec, pbi_apply_page_spec, or the pbi_build_* tools, and there are no prerequisites or exclusions.
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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states what the tool returns (rules and their correction details) but does not explicitly say whether the operation is read-only, requires a selected model, or has any side effects. For a list tool, some of this is implied, but the description does not confirm safety or behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (in Spanish) that states the object and its detail in under ten words. It is front-loaded with the key concept ('reglas que tienen correccion automatica') and contains no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless list tool, the description adequately explains the purpose and content. An output schema exists, so return-value details are not the description's job. It could mention whether the list is global or model-specific, but given the tool name and sibling context, the current level is sufficient. Slightly more context about the correction types would push it to 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there is nothing for the description to add. The baseline of 4 applies here since the description does not need to compensate for missing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (autofix rules) and states the scope: only rules that have automatic correction. It distinguishes from the sibling pbi_list_audit_rules by narrowing to 'correccion automatica'. However, the description is a noun phrase rather than an explicit verb phrase like 'List...', so it slightly underuses the directness of the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. While the sibling list suggests it is the go-to for autofix rules, there is no explicit mention of when to prefer this over pbi_list_audit_rules or pbi_plan_audit_fixes, nor any exclusions or prerequisites.
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 no annotations provided, the description carries the full burden. The verb 'lista' strongly implies a read-only operation, and it states what data is covered. However, it does not explicitly disclose that it performs no modifications or mention any limitations, permissions, or side effects. It adds some behavioral context but leaves safety implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the main action and includes meaningful detail about the returned data. There is no filler or redundancy; every word 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (so return values are presumably covered), the description omits critical context about the 'source' parameter, which is likely important for selecting between live and project models in this Power BI toolset. The description is too terse to fully guide an agent in a complex environment with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, 'source', with a default of 'live' and zero description coverage. The tool description does not mention this parameter at all, so the agent has no indication what values are accepted or what 'live' means. The description fails to compensate for the schema's lack of documentation, making the parameter essentially a mystery.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists relationships and enumerates the specific attributes returned (tables/columns, cardinality, cross filter, status). This is a specific verb+resource and distinguishes it from sibling list tools like pbi_list_tables or pbi_list_measures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when relationship metadata is needed, but it does not explicitly state when to use this tool versus alternatives like pbi_set_relationship_direction or pbi_list_tables. No when-not-to-use or alternative guidance is provided, so it rests at implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states 'No escribe nada' (writes nothing), confirming a non-mutating operation, and describes that errors include JSON paths for correction. This adds meaningful context beyond the tool's name, though it does not cover potential permission requirements or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary purpose, and includes two important behavioral details (non-mutation and error paths) in a compact format. Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a validation tool with a single parameter and an output schema, covering validation scope, non-mutation, and error reporting. However, it lacks a definition of what constitutes a valid spec, which is a notable gap given the parameter is weakly defined in the schema. The existence of an output schema reduces the need to explain return values, but the input ambiguity affects completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 0% description coverage, and the description does not compensate by defining what a 'spec' is or its expected structure. It only refers to 'un spec' without detailing required fields, formats, or constraints. The schema's 'additionalProperties: true' is unhelpful, leaving the agent unable to construct a valid spec parameter confidently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it validates a spec, specifically schema, references against the model, and geometry. This is a specific verb+resource combination that clearly indicates the tool's function. It does not explicitly differentiate from sibling validation tools like pbi_validate_measures or pbi_validate_pbip_project, but the focus on page spec is clear from the tool name and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios, exclusions, or alternatives, leaving the agent to infer usage solely from the tool's name and purpose. There is no explicit 'when to use' or 'when not to use' 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: without arguments it registers 'HTML Content', which renders HTML/SVG from a DAX measure, and that Power BI Desktop downloads it from AppSource when opening the report. However, it does not disclose what happens when visual_id is provided, potential side effects, or error conditions. This is a moderate level of 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that front-load the primary purpose. The first sentence states the core action, and the second adds the key default behavior and downstream effect. Every sentence earns its place with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with two optional parameters and an output schema, so the description doesn't need to explain return values. It covers the primary purpose and a key default behavior. However, it omits details about the meaning of visual_id and request_id, and lacks any usage guidance or prerequisites, making it not fully complete for an agent to invoke correctly in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It only explains that with no arguments the default 'HTML Content' is registered, implying visual_id is optional. It does not explain what visual_id represents or how to specify other visuals, and request_id is entirely unexplained. This leaves significant semantic gaps for the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Registra un custom visual de AppSource en el informe' (registers an AppSource custom visual in the report). It also specifies the default resource ('HTML Content') when no arguments are provided, which distinguishes it from related tools like 'pbi_create_visual' or 'pbi_create_html_visual'. The verb 'registra' and the target 'custom visual de AppSource' make 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like 'pbi_create_visual' or 'pbi_create_html_visual'. It mentions the default behavior with no arguments but does not state when a user should choose this tool over another or any exclusions. Usage context is only implied by the tool's name and description, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It clearly states the tool is non-destructive ('No escribe al .pbip') and that the preview is exactly what would be written, drawing data from the same compiled source. This is transparent about side effects and accuracy, though it does not mention any other constraints 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the core purpose. The first sentence states what the tool does; the second clarifies non-mutation; the third explains the preview's fidelity. Every sentence contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description is incomplete for practical use. It does not explain how to construct the required 'spec' parameter (beyond listing its content categories) or what the 'seed' parameter does. It also lacks any prerequisites or context on when this preview is appropriate relative to the broader workflow. The description covers the tool's behavior well but not its input requirements sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It mentions that the spec includes types, titles, fields, sizes, and positions, giving some context for the 'spec' parameter. However, it does not explain the structure of the spec object, and the optional 'seed' parameter is completely unmentioned, leaving a significant semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an HTML mockup of a page spec with final positions, and explicitly notes it does not write to the .pbip file. This makes the purpose clear and distinguishes it from write tools, but it does not explicitly differentiate from the closely named sibling pbi_preview_spec_html.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use it to view an accurate preview before writing, since it states the preview matches exactly what would be written and that it does not write to the .pbip. However, no explicit when-to-use or when-not-to-use guidance, nor alternatives, are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that findings include evidence and that no heuristic is presented as certainty, adding useful behavioral context. However, it does not state whether the operation is read-only, requires an active model, or has other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the purpose, and each sentence adds meaningful detail without redundancy. It effectively covers the key aspects in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, and the description adds field details and evidence behavior. However, the missing explanation of the 'source' parameter and lack of prerequisites (e.g., model selection) leave gaps in full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description partially compensates for 0% schema coverage by explaining 'rules' as a subset of rules and listing allowed values for 'min_severity'. However, the 'source' parameter is not mentioned at all, leaving its meaning unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits the semantic model with stable identifier rules, using a specific verb and resource. It distinguishes itself from sibling tools like pbi_audit_project and pbi_audit_report_only by focusing on the model-level audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It references pbi_list_audit_rules for rule details, but does not mention when not to use it or how it compares to similar audit/analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the transparency burden. It lists the returned fields, which is helpful, but it does not explicitly state read-only behavior, error conditions, or permission requirements. The name 'get' implies a query, but without annotation support, the disclosure is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a lead phrase defining the tool and a second sentence enumerating the returned data. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 a straightforward getter operation, the description is sufficiently complete. It lacks parameter guidance but covers the purpose and return contents well. The sibling context helps, though not mentioned. Overall, it is adequate for a visual detail retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not explain the 'page' and 'visual_id' parameters. The parameter names are self-explanatory to some extent, but the description adds no additional meaning, leaving the agent to infer how to identify the visual.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a complete and normalized definition of a visual, enumerating specific attributes (type, position, z-order, title, fields, measures, columns, format, filters, raw definition). This distinguishes it from sibling tools like pbi_list_visuals (listing) and pbi_get_object (generic) by specifying the full detail 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or alternative guidance is provided. The description only defines what the tool returns, not when to choose it over other visual-related tools. It does not mention exclusions, prerequisites, or sibling comparisons.
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 no annotations, the description carries the burden of disclosing behavior. 'Catalog' implies a read-only listing operation, and it mentions the returned content (domain and severity), but it does not explicitly confirm the absence of side effects or any prerequisites. This is adequate for a simple list tool but lacks thoroughness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the core purpose and includes relevant details about the output content, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with an output schema, the description provides sufficient context: it names the tool's purpose and the fields of interest. It does not explain usage context, but that is not essential given the simplicity, and the output schema handles return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and it adds value by indicating what the returned data includes (domain and severity), which partially compensates for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a catalog of available audit rules with domain and severity, which identifies the resource and scope. It distinguishes from siblings like pbi_list_autofix_rules by specifically mentioning 'audit rules,' though it does not explicitly use the verb 'list' from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as pbi_audit_project or pbi_list_autofix_rules. The description simply states what the tool is, with no context on when it should be invoked.
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 no annotations, the description carries the transparency burden. It adds useful context about what a preset represents (intention of the page), but does not disclose return format, read-only status, or any behavioral constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the purpose, followed by a clarifying conceptual note. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with an output schema, the description is sufficient to understand what it returns and why it matters. It could mention read-only behavior or relation to page creation, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description provides meaningful context about the output's conceptual content. This meets the baseline for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available page presets and their composing blocks, which is a specific resource. It distinguishes from siblings by focusing on presets rather than spec generation or building blocks directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 pbi_page_building_blocks or pbi_generate_page_spec. The conceptual explanation implies it supports page creation, but no clear context or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a valuable behavioral trait: preserving the visual's format (font, color). However, it does not mention permissions, error handling, reversibility, or side effects, leaving significant gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential action and key behavioral guarantee. It is concise and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no annotations, yet the description provides no usage guidelines or parameter semantics. While an output schema exists to explain return values, the description is insufficient for an agent to reliably select and invoke this tool among many similar siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its 4 parameters, and the description adds minimal value. 'Title' is implicitly covered by the tool's purpose, but 'page', 'visual_id', and 'request_id' are not explained, so the agent must infer their roles from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('cambia') and resource ('titulo de un visual'), clearly stating what the tool does. It also distinguishes from sibling tools by explicitly noting that it preserves formatting, which is not obvious from the name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (changing a visual title) and adds a key constraint (preserving format), but it does not explicitly mention when to use this tool over alternatives or provide any exclusion criteria. Given the large number of sibling tools, some guidance would be helpful.
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 no annotations, the description carries the burden of behavioral disclosure. It adds useful context about checking broken references and geometry, and that it performs deep validation. However, it does not explicitly state whether the tool is read-only, requires specific permissions, or has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and provides usage context in the second sentence. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description gives a clear usage scenario, it omits critical parameter semantics and behavioral guarantees (e.g., read-only status). The existence of an output schema helps, but the agent cannot reliably construct a correct invocation without knowing how to specify 'page'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'page' is a string with no schema description, and the description does not explain what value to pass (e.g., page ID, name, or path). With 0% schema coverage and no compensation in the description, the agent is left guessing the parameter format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: verifying an already written page for broken references and geometry. It distinguishes itself from sibling validation tools by explicitly noting it runs after applying a spec, focusing on the generated page rather than the spec itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states explicitly when to use it ('después de aplicar un spec') and clarifies that it checks actual validity, not just whether writing succeeded. It implies it is not for validating the spec itself, though it does not name an alternative tool.
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?
Without annotations, the description must carry the full behavioral disclosure. It does not state whether this validation is read-only, what prerequisites exist (e.g., a connected model or open project), or what side effects might occur. The description only lists what is checked, leaving safety and operational behavior unknown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource ('Valida a fondo el proyecto .pbip activo') and then adds clarifying details. No wasted words, fully focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 params) and has an output schema, so return values need not be described. The description covers the core purpose and scope (structure, PBIR, TMDL). However, it lacks any usage context or behavioral caveats, such as what to do with the results or when to choose this over other validators, leaving the completeness just at the minimum viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100% (vacuously). Per the rubric, a 0-parameter tool receives a baseline of 4. The description adds no parameter details because there are none to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Valida a fondo' = thoroughly validates) on a specific resource ('el proyecto .pbip activo' = the active .pbip project), and further specifies what is validated (structure, PBIR, TMDL). This clearly differentiates it from sibling validation tools like pbi_validate_measures or pbi_validate_page_spec, which target narrower scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is the comprehensive project-level validator, nor does it exclude use cases better suited for pbi_health_check, pbi_audit_project, or pbi_validate_measures. The only implied usage is from the tool name and general validation context, which is insufficient.
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?
No annotations are provided, so the description carries the full burden. It discloses the types of dependencies checked and the outcome ('dice si algo se rompe' - tells if something breaks), adding some behavioral context. However, it does not mention whether the operation is read-only, potential performance implications, or the return format, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences, no fluff. The first sentence front-loads the main purpose, and the second provides a practical usage tip. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys the core purpose and a key use case, which is sufficient for a simple analysis tool. However, the complete absence of parameter explanations (especially 'source') and the lack of annotation coverage leave an agent uncertain about input semantics. An output schema exists, so return values are not needed in the description, but the parameter gap reduces overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any parameters. It only refers to 'column' in the purpose, but does not clarify 'table', 'column', or especially 'source' (which has a default of 'live'). The description completely fails to compensate for the lack of schema-level parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it identifies what uses a column (measures, calculated columns, relationships, hierarchies). The verb 'usa' (uses) and resource 'columna' (column) make the purpose specific, and it distinguishes itself from the sibling tool pbi_measure_dependencies by focusing on column dependencies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Util antes de ocultar o eliminar una columna' (useful before hiding or deleting a column). It clearly indicates when to use the tool, though it does not explicitly mention alternatives or exclusions, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and discloses meaningful behaviors: preservation of fields/format/filters, regeneration of a unique identifier, and offset placement to avoid overlap. However, it omits potential side effects, error conditions, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and uses three focused sentences to explain behavior and key parameters. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters and an output schema, yet no annotations. The description explains the main duplication behavior and a few parameters but omits details like return values, error handling, and the effect of new_title when null. It covers essentials but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains offset_x/offset_y and target_page, but leaves new_title, request_id, page, and visual_id without added meaning beyond schema titles, especially ambiguous ones like request_id and new_title's default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool duplicates a visual while preserving its fields, format, and filters, using a specific verb and resource. It distinguishes from sibling tools like pbi_duplicate_page or pbi_copy_visual_format by focusing on full visual duplication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by defining the tool's behavior but does not explicitly compare to alternatives such as pbi_copy_visual_format or pbi_create_visual. It mentions the target_page option for copying to another page, but no when-to-use or when-not-to-use guidance 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?
With no annotations provided, the description carries the burden of disclosing behavior. It adds useful behavior for measures (inclusion of DAX references), but it does not state that the operation is read-only, whether errors occur for invalid names, or what 'all detail' includes. This is a partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with a clear main statement followed by a compact list of kind specifics. Every sentence adds value, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, return values need not be described. The required parameters are covered well, and the tool is simple (3 params, 2 required). The only notable omission is the 'source' parameter, which is optional with a default, so overall completeness is high but not perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It explains 'kind' allowed values and the column naming format, and clarifies that 'name' uses 'Table[Column]' for columns. However, the 'source' parameter (optional, default 'live') is not mentioned, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a model object with all its detail ('Devuelve un objeto del modelo con todo su detalle') and specifies supported kinds (table, column, measure). It is distinct from sibling tools like pbi_list_tables or pbi_get_visual, though it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: the description indicates you specify a kind and name, with a naming convention for columns ('Tabla[Columna]') and notes that measures include DAX references. However, it lacks explicit guidance on when to prefer this tool over other model-inspection tools like pbi_measure_dependencies or pbi_list_partitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. The verb 'Lista' clearly indicates a non-mutating read operation, and the listed output fields describe what the call returns. It does not mention all side-effect details, but for a list operation this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no superfluous words. It immediately states the action and the key output attributes, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema, the description adequately communicates the return contents. However, it omits any explanation of the 'source' parameter, and given many sibling tools, a note about scope (e.g., current selected model) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('source') with no schema description and 0% coverage. The tool description does not mention or explain this parameter at all, leaving its meaning and valid values completely unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lista') and resource ('medidas') and explicitly names the output fields (tabla, expresion DAX, formato, descripcion y carpeta). This clearly distinguishes it from sibling list tools like pbi_list_tables and pbi_list_partitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to list measures, but it provides no explicit guidance on when to prefer this over related tools such as pbi_list_tables or pbi_validate_measures. There are no exclusions or alternative tool mentions.
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?
No annotations are provided, so the description carries the full burden. It discloses notable behavior: 'Clona un visual del mismo tipo como plantilla si existe. Hace backup.' (Clones a visual of the same type as a template if it exists, backs up). This adds non-obvious context, but it does not explain other potential side effects, prerequisites, or failure modes, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear opening sentence, followed by parameter definitions in code-style formatting. It adds no fluff; every line serves a purpose. The cloning and backup note is included efficiently at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested objects and an output schema, so return values are handled. However, the description lacks contextual completeness in terms of when to use this tool relative to other visual-creation or duplication tools, and does not mention any dependencies or conditions (e.g., page must exist). It is adequate but not thorough for a tool with many visual-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides concise but valuable parameter documentation for visual_type, fields, and position, including allowed values and structure examples. However, it does not explain 'page', 'title', or 'request_id', though these are relatively self-explanatory. This significantly exceeds the schema's bare type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear statement: 'Crea un visual PBIR en una pagina' (Creates a PBIR visual on a page). This specifies the action (create), resource (visual), and context (on a page), distinguishing it from sibling tools like pbi_create_html_visual or pbi_duplicate_visual.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as pbi_duplicate_visual or pbi_create_html_visual. The description only states what it does and provides parameter examples; it does not mention conditions, prerequisites, 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?
With no annotations provided, the description carries the full burden of behavioral transparency. It discloses a key validation behavior: if the expected measures are not recognized, the tool warns instead of generating a meaningless page. This goes beyond the basic creation action and provides useful safety context, though it does not mention other behaviors like error handling, permissions, or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that immediately state the purpose, then explain the validation behavior. Every word earns its place, and the key information is front-loaded. There is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no schema descriptions, a complete description would need to address all parameters or point to the output schema. The description effectively covers the core purpose and the key behavioral nuance, but it leaves name, seed, dry_run, and category unexplained. The output schema exists but does not help the agent understand parameter semantics, so the description is only minimally complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its 5 parameters, so the description must compensate. It adds meaning to the required 'measures' parameter by listing the expected types (PV, EV, AC, CPI, SPI), but it entirely ignores the other parameters (name, seed, dry_run, category). Thus, it only partially compensates for the lack of schema descriptions, leaving significant ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: building an EVM (Earned Value Management) page, and specifies the expected measure types (PV, EV, AC, CPI, SPI). The verb 'build' and resource 'EVM page' are specific and distinguish it from sibling page-building tools that target other types of pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when this tool should be used (when creating an EVM page with relevant measures) and mentions a validation behavior (warns if measures are unrecognized). However, it does not explicitly state when not to use it or mention alternatives like pbi_build_executive_page or pbi_build_dashboard, leaving some ambiguity for an AI agent choosing among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool reports additions/removals/same visuals and warns when a page does not exist, but it does not explicitly state whether it modifies data or any permission requirements. The read-only nature is only implied by 'antes de aplicarlo', leaving a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, with the main action stated first and supporting details following. Each sentence adds meaningful information without redundancy, achieving excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema already covers return values, so the description need not detail them. It explains key scenarios (existing vs. missing page) and what the diff reports. While it omits error cases, this is sufficient for a diff tool with simple parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It clarifies that 'page' refers to an existing page and that a non-existent page triggers a creation message, but it does not describe the structure of the 'spec' object or how pages are identified (e.g., by name or ID). This is partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares a spec against an existing page, reporting which visuals would be added, removed, and remain unchanged, and handles non-existent pages. This distinguishes it from sibling tools like apply or preview, as the verb 'compara' plus resource and output details make 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'antes de aplicarlo' implies a workflow context before applying a spec, but it does not explicitly name alternative tools or state when not to use this tool. The usage guidance is implied rather than explicit, making it adequate but not strong.
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 no annotations, the description carries the full burden. It discloses the minimum count and axis options, but does not mention side effects such as whether positions are permanently modified, what happens to the first/last visual, or any permission requirements. Partial disclosure only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an inline definition of 'axis'. Every word contributes value—stating the action, the parameter, and the minimum requirement. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and a key constraint (three visuals), but given it is a mutation tool, it lacks details about the distribution algorithm (e.g., are endpoints fixed?) and potential side effects. The output schema exists but does not compensate for these missing behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains 'axis' (horizontal|vertical). The other parameters (page, visual_ids, request_id) are left to inference from their names, which is insufficient given no schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Reparte visuales con separacion uniforme' (distributes visuals with uniform separation). It specifies the 'axis' parameter and the specific operation, distinguishing it from siblings like align or arrange by focusing on uniform distribution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear usage condition: requires at least three visuals, and explains behavior with two ('con dos, la separacion ya es la que hay'). This gives practical context on when to use the tool, though it does not explicitly contrast with alternatives like pbi_align_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?
With no annotations, the description carries the full burden. It discloses that the tool saves a file to outputs/ and includes certain sections, but it does not explain prerequisites (e.g., connected model), side effects (e.g., overwriting files), or the exact return structure beyond the file creation. It doesn't contradict any annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and lists the key inclusions and output location. No extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with multiple output sections and an output schema. The description lists what's included but lacks guidance on model selection, the difference between source options, and how the output integrates with other tools. It is adequate but not fully complete for an autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides two parameters with no descriptions, and the description has 0% coverage of schema details. The description only indirectly hints at include_quality through 'advertencias de calidad' but does not explain the source parameter or its possible values. This leaves the agent guessing about parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates complete model documentation in Markdown, specifying the resource (model) and output format. It lists the included sections (summary, tables, columns, measures, relationships, hierarchies, roles, quality warnings), distinguishing it from more focused tools like pbi_model_summary or pbi_analyze_model_quality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when comprehensive model documentation is needed, including all schema elements and quality warnings. However, it does not explicitly mention alternatives or when not to use it, such as when only a summary or audit is needed, which are provided by sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the basic action of generating documentation. It lacks information about side effects, safety, or any prerequisites. The description is too minimal to provide full 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence in Spanish that front-loads the verb and clearly states the resource and scope. There is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and has an output schema. The description clarifies the scope (pages and visuals) and is adequate for this simple tool, though it lacks some context about the report being documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema reflects that. With zero parameters, the baseline is 4, and the description does not need to compensate for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates Markdown documentation of the report layout, specifically pages and visuals. This distinguishes it from siblings like pbi_document_model and pbi_generate_technical_documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for documenting report layout but does not explicitly state when to use this tool versus alternatives like pbi_document_model or pbi_generate_technical_documentation. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It indicates the output is a draft ('borrador') and editable, implying no direct mutation, but it does not explicitly say whether it modifies anything or what side effects exist. The mention of validation adds context but not full 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single opening sentence, a compact list of key parameters, and a clear follow-up instruction. Every part earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (covering return values) and the tool is a generator, the description covers the main workflow and key parameters. It lacks explicit mention of `page_name` and width/height, but those are straightforward. Overall it is sufficiently complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does explain `preset`, `measures`, and `category` with meaningful detail, but it omits `page_name` (a required parameter) and leaves `width`/`height` to be inferred from schema names. Partial compensation but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a draft spec from a preset and fields, with a specific verb and resource ('Genera un borrador de spec'). It differentiates from validation/apply tools by explicitly mentioning the follow-up validation step, but does not distinguish itself from the similarly named pbi_generate_report_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for generating an editable spec draft, and it instructs the user to review it and pass it through pbi_validate_page_spec. It does not explicitly state when not to use it or name alternatives, but the workflow guidance is useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently explains that with dry_run=true it only proposes corrections, and with dry_run=false it applies them and compares scores. This clearly signals the potential mutating behavior, which is critical for an agent to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the summary line 'Checklist de pre-entrega con plan de correccion.' It then provides necessary details in a compact two-sentence structure with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core workflow (audit, checklist, corrections, dry-run behavior) and since an output schema exists, return values are likely specified there. However, it lacks an explanation of request_id and does not detail what specific corrections or blockers are involved, leaving some context to be inferred.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly explains the dry_run parameter: 'Con dry_run=false las aplica y compara el puntaje antes y despues.' However, it does not mention the request_id parameter at all. Since schema coverage is 0%, the description partially compensates by explaining one of two parameters, but not the other.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it audits the project, produces a blocker checklist, and proposes available automatic corrections. The term 'pre-entrega' gives specific context, but it does not explicitly differentiate from sibling audit tools like pbi_audit_project or pbi_plan_audit_fixes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through 'Checklist de pre-entrega' (pre-delivery), suggesting when to use it. However, there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description lacks a clear 'use this when...' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that only the visible name changes while the internal ID persists, which is a useful behavioral trait. However, with no annotations, it doesn't mention side effects, required permissions, or failure conditions. It adds some value but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action. It wastes no words and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple rename operation, the description covers the core behavior and the critical invariant (internal ID unchanged). However, it omits any information about return values, error conditions, or prerequisites. Given its simplicity, it is minimally sufficient but could benefit from a bit more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies that 'new_name' sets the visible name, but the 'page' parameter is not explained (e.g., ID vs. name). The 'request_id' parameter is entirely undocumented. With zero schema description coverage, the description should provide more parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: changing a page's visible name. It also clarifies that the internal ID remains unchanged, which distinguishes it from affecting structural identity. No ambiguity with 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for renaming report pages. It doesn't explicitly mention alternatives or exclusions, but since no sibling tool performs renaming, the context is clear. However, it lacks explicit guidance on when to use vs. other page operations.
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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It explains the stateful nature (selecting an active model affects future operations) and the port requirement conditional. However, it does not disclose potential side effects, persistence scope, or what 'active' means, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two short sentences. The first sentence states the core purpose, and the second adds essential conditional usage detail. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but the description omits the `catalog` parameter and doesn't clarify the persistence/scope of the selection. It does leverage the output schema and sibling reference, but the catalog gap and lack of annotation make it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the `port` parameter's optionality and where to find values, but completely ignores the `catalog` parameter. With two parameters, only one is semantically explained; the other remains undocumented, a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Selecciona') and resource ('modelo local activo'), clearly stating it selects the active local model for future operations. It also distinguishes itself from sibling pbi_list_desktop_models by referencing that tool as the source for port values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear conditional guidance: if only one model is open, no port is needed; if multiple, pass the port from pbi_list_desktop_models. It does not explicitly say when not to use the tool or mention alternatives, but the conditional logic and sibling reference provide solid usage 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?
With no annotations provided, the description takes on the burden of disclosing side effects and operational nuances. It warns that changing to 'single' may alter totals that depended on bidirectional filtering, and advises verifying the report afterward. It also explains the temporary disablement of mode='both' and the distinct requirements of 'live' vs 'pbip' modes. This is above-average transparency, though it does not mention permissions or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized: a one-sentence purpose, followed by detailed parameter semantics in a code block. The caution about direction='both' and mode='both' is valuable but adds density. Every sentence serves a purpose, though the mode explanation could be clearer for non-experts. Overall, it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description addresses key behavioral aspects (direction side effects, mode behavior) and there is an output schema to explain return values. However, it does not clarify how relationships are uniquely identified when multiple relationships exist between the same two tables, and it does not explain the purpose of 'request_id'. Given the moderate complexity and lack of annotations, the description is mostly complete but has notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains the 'direction' parameter ('single' vs 'both') and the 'mode' parameter (live vs pbip, including the constraint that mode='both' is disabled). However, it does not explain 'from_table' and 'to_table' beyond their names, nor does it mention 'request_id' at all. Some parameters are self-explanatory, but the incomplete coverage warrants a mid-range score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Cambia el filtro cruzado de una relacion' (changes the cross-filter of a relationship). This clearly distinguishes the tool from siblings like pbi_list_relationships (which lists relationships) and pbi_set_column_visibility (which changes column visibility). No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the action and explaining parameter values, but it does not explicitly state when to use this tool versus alternatives (e.g., when a relationship exists but needs its cross-filter direction changed). No exclusions or alternative recommendations are provided. The 'No confundir' note is a caution about parameter naming, not about when to use the 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?
With no annotations provided, the description carries the full burden. It discloses key behaviors: validation of table/measure existence, the overwrite behavior, the data_category rendering context, the mode restriction ('both' disabled), and that it returns a diff. This is substantive, though it omits details like permission requirements and error handling specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with a clear opening statement about the core action, followed by validation behavior, an optional parameter example, a note about return value, and a mode restriction warning. It is moderately concise and front-loaded, though the mode='both' explanation adds length but earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no annotations, 0% schema coverage), the description covers the main purpose and a few key parameters but leaves many parameters unexplained. The existence of an output schema somewhat mitigates the need to describe return values, but the incomplete parameter documentation limits contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all 10 parameters. It only explains data_category (with an example) and mode (with the live/pbip/both distinction), and partially implies overwrite semantics. The other seven parameters (table, name, expression, description, format_string, display_folder, request_id) are left undocumented in both the schema and description, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or replaces (with overwrite=true) a DAX measure, using the specific verb 'crea' and the resource 'medida DAX'. It distinguishes itself from sibling tools like pbi_update_measure and pbi_delete_measure by focusing on creation/replacement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it validates that the table exists and that the measure doesn't already exist unless overwrite is true. It also gives explicit guidance on the mode parameter, explaining that 'both' is disabled and advising to choose 'live' or 'pbip'. However, it does not explicitly exclude alternatives like pbi_update_measure when modifying an existing measure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two behaviors: it clones existing visuals of the same type as a template and makes a backup. However, since there are no annotations, it does not cover side effects like whether an existing page is overwritten, permission requirements, or error conditions. This leaves important behavioral gaps for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the main purpose in the first sentence, followed by a structured spec example and behavioral notes. It uses a code block for clarity. It could be more organized, but it is appropriately sized and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (full-page creation with visuals, cloning, backup, layout) and the description provides a spec structure but omits prerequisites, return values, error handling, and field details like 'rol:refs'. An output schema exists, but the description itself leaves several gaps, making it only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage, showing only a generic 'spec' object and 'request_id'. The description compensates by providing the detailed spec structure: {page_name, canvas?, layout?, visuals:[...]}, explains the 'position' field, and clarifies that omitting it triggers auto-arrangement. This fully covers the main parameter's semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Crea una hoja (pagina) PBIR completa a partir de un spec' (creates a complete PBIR page from a spec). It specifies the input structure and distinguishes itself from sibling tools like pbi_create_visual or pbi_apply_page_spec by emphasizing full-page creation and cloning of existing visuals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the spec structure and mentions auto-layout via layout and position omission, but it does not explicitly state when to use this tool over alternatives like pbi_apply_page_spec or pbi_generate_report_page. There is no 'when not to use' or direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It explains the tool is informational and describes the cloning constraint, but it doesn't explicitly state that it's a read-only operation or disclose any side effects, permissions, or return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence lists the output categories, and the second explains the rationale for the tool's existence. Both sentences earn their place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an output schema present, the description is complete enough. It tells the agent why this tool matters (cloning constraint) and what information it provides. It doesn't need to explain return values due to the output schema, and the context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is vacuous. The baseline for no params is 4, and the description adds context about the output categories (PBIR version, theme, custom visuals, clonable types), which is helpful even though there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool reports observed PBIR version, theme, custom visuals, and clonable visual types. It clarifies that it enumerates which visual types are available for cloning, distinguishing it from creation tools. The verb is implicit ('dice cuales hay disponibles') but the intent is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames the tool as a prerequisite: only existing visual types can be cloned, so you should consult this tool before attempting to create visuals. This gives a clear when-to-use context and the underlying reason, though it doesn't mention alternatives 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?
With no annotations, the description carries full burden. It discloses case-insensitive search ('sin distinguir mayusculas'), that it searches in measure DAX, and that for measures it indicates whether the name or expression matched. It does not cover limit/source behavior or error handling, but the disclosed traits are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-structured. The primary purpose appears in the first sentence, and parameter details are formatted with backticks for readability. Every sentence provides useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are covered. However, the description omits semantics for 'limit' and 'source', and there are no annotations to clarify behavior. Given the tool's moderate complexity and important context around 'source' (likely live vs. pbip), the description has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'term' (case-insensitive text) and 'kinds' (filters by type), but does not describe 'limit' or 'source'. The latter is particularly ambiguous, and the schema offers no descriptions either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Busca objetos del modelo por nombre (y en el DAX de las medidas)', clearly stating it searches model objects by name and within measure DAX. This distinguishes it from sibling list/get tools by focusing on search behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool to find model objects matching a term, optionally filtered by kind. However, it provides no explicit when-to-use versus alternative tools, no exclusions, and no mention of when not to use 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?
With no annotations, the description carries the full burden. It discloses important behavioral traits: it verifies the project state and rejects the plan if changes occurred, and it supports an optional expected_operation check that returns 'plan_operation_mismatch'. This goes beyond what annotations would provide, though it does not mention permissions, rollback, or the full impact of applying the plan.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each serving a distinct purpose: main action, safety check, and optional parameter explanation. It is front-loaded with the core purpose and contains no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior and the safety mechanism, and the output schema covers return values. However, with 4 parameters and no schema descriptions, the lack of detail on 'plan_token', 'confirm', and 'request_id' makes the description incomplete for a tool that applies potentially significant changes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains the 'expected_operation' parameter, detailing its optional nature and the mismatch error. The other three parameters (plan_token, confirm, request_id) are not explained at all, leaving a significant gap in understanding required inputs and controls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Aplica un plan calculado con pbi_plan_change o con un dry_run.' It specifies a concrete verb ('aplica') and resource ('plan'), and references the sibling tool pbi_plan_change to distinguish plan creation from application, effectively differentiating it from other apply-type 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: the plan must have been generated by pbi_plan_change or a dry run. It also describes a prerequisite condition (the project state must match the planned state) and the failure behavior. However, it does not explicitly contrast with alternatives like pbi_apply_audit_fixes or state when not to use this tool.
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 no annotations, the description discloses that it creates a timestamped backup and returns the path. It does not elaborate on side effects, permissions, or preconditions, so it only partially covers 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the main purpose in one sentence and parameter options in a single line. Every word contributes, making it highly efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and an output schema, the description is largely sufficient. It explains the core behavior, parameter options, and return value. Minor gaps like prerequisite conditions (active project) are not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, but the description enumerates the accepted values for both parameters ('folder | zip' and 'report | model | both') and notes the return value. However, it does not explain what each option means, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Crea'), resource ('.pbip project'), and qualifiers ('con timestamp', 'activo'). It clearly distinguishes from sibling tools like pbi_purge_backups and pbi_recover_from_journal, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a backup creation tool via context, but it does not explicitly state when to use it versus alternatives, nor does it mention exclusions or prerequisites such as requiring an open project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose key behaviors: it outlines the workflow (analyze model, compose spec, calculate layout, generate preview, apply in transaction, verify) and importantly states that dry_run=true (default) stops after preview. This reveals the tool's safe-by-default execution mode but does not detail side effects of applying or what verification entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs with no wasted words. The opening line is a crisp purpose statement, followed by a compact step list and a critical flag note. Every sentence adds value and the structure is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (6 parameters, multi-step workflow) with no annotations and an output schema that likely defines return values. The description provides a high-level workflow and dry_run behavior but omits essential details like how the 'objetivo' is expressed in parameters, what presets are available, and prerequisites such as requiring a selected model. It is a minimal viable description but has clear gaps for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meanings. It only explains dry_run (default true, stops after preview), leaving name, measures, seed, preset, and category undefined. This is insufficient for an agent to know what values are expected or how they relate to the 'objetivo'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds a complete dashboard from an objective, not from primitives, using the verb 'Construye' with a specific resource and scope. It distinguishes itself from sibling tools like pbi_build_executive_page or pbi_create_visual by emphasizing the high-level 'objetivo' approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use: when you have an objective rather than building from primitives. It also gives explicit guidance about dry_run default behavior, informing the agent it can preview before applying. However, it does not explicitly name alternative tools or state when not to use 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?
With no annotations, the description carries the full burden. It discloses two non-obvious behaviors: the title text is not copied (treated as content), and cross-type copying is rejected because the format structure is not interchangeable. This is useful behavioral context beyond the simple 'copy format' operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, both of which carry meaningful information. It is front-loaded with the core purpose and adds constraints without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key constraints but lacks parameter-level detail. It mentions the same-type restriction and title exclusion, but does not explain how to specify targets, what happens if targets are invalid, or what the output contains. Given the tool has 5 parameters and no parameter documentation, this is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter semantics. It never mentions source_page, source_visual, target_page, or target_visuals, nor how visuals/pages are identified (names, IDs, etc.). The parameter names in the schema are somewhat self-explanatory, but the description adds no value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool copies the format of one visual to other visuals of the same type ('Copia el formato de un visual a otros DEL MISMO TIPO'). It distinguishes this from sibling tools like pbi_duplicate_visual (which copies the whole visual) and pbi_set_visual_title (which only sets the title).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it copies format only, not the title text, and explicitly warns that copying between different visual types is rejected. It does not explicitly name alternative tools, but the constraints are strong enough to guide an agent to use this tool for format replication only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is transactional ('en una sola transaccion'), regenerates unique identifiers for the page and visuals, and preserves everything else. This goes beyond a generic 'duplicate page' statement, though it doesn't cover error cases or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences immediately state the operation and then add critical behavioral detail. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple duplication operation, with output schema available for return values. However, it leaves usage guidance and parameter semantics mostly implicit, and there is no annotation support, so the agent might be uncertain about prerequisites or request_id handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It implies that 'page' is the source page and 'new_name' is the new page name via the duplication semantics, but it never explicitly maps them or explains 'request_id'. The description adds limited value beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Duplica') and resource ('una pagina con todos sus visuales'), clearly distinguishing it from sibling tools like pbi_duplicate_visual (duplicates a visual) and pbi_delete_page (deletes a page).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the use case: copying a page and all its visuals in one operation. It does not explicitly name alternatives or exclusions, but the context is unambiguous enough for an agent to select it over related page operations.
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 no annotations, the description carries the full burden. It does disclose the output content (columns, types, visibility, counts) and the two source modes ('live' vs 'pbip'), which is useful. However, it does not explicitly state that this is a read-only operation, nor does it mention any side effects or permissions required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the main purpose front-loaded. The parameter explanation is compact and informative, without redundant phrasing or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and an output schema, the description adequately covers the core behavior and parameter semantics. It could additionally explain when 'live' versus 'pbip' might be preferred, but the current level is sufficient for basic selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a default value with no description, and schema coverage is 0%. The description compensates by explaining the 'source' parameter's allowed values ('live' for open model, 'pbip' for TMDL files) and the default. This gives the agent enough semantic meaning to choose an appropriate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Lista tablas con columnas, tipos, visibilidad y conteos', which clearly names the action (lists), the resource (tables), and the specific details returned. This distinguishes it from sibling tools like pbi_list_partitions or pbi_list_measures by focusing on tables and their metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a user needs table metadata (columns, types, visibility, counts) but does not explicitly state when to prefer this over alternatives such as pbi_model_summary or pbi_list_partitions. There are no exclusionary criteria or alternative tool mentions beyond the 'source' parameter options.
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 no annotations provided, the description carries the behavioral disclosure burden. It does disclose what information is returned (fields list), but it does not mention read-only status, error conditions, pagination, or ordering. This is adequate for a simple listing tool but lacks deeper 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the tool's purpose, and includes parameter documentation inline. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward list tool with a single parameter and an output schema present, the description covers the essential information: what it lists, the fields returned, and the meaning of the input. It does not explain return value structure in text, but the output schema presumably handles that. Minor gaps include no mention of error handling or ordering, which are not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter with 0% description coverage. The description compensates by explaining the `page` parameter meaning: 'id interno o nombre visible de la pagina' (internal id or visible page name). This adds useful semantic value beyond the bare schema, though it could include examples or accepted formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists visuals of a page, and enumerates the fields returned (id, type, position, fields, title). It uses a specific verb ("Lista") and resource ("visuales de una pagina"), and is distinct from sibling tools like pbi_get_visual (which fetches 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The implied use case is to retrieve all visuals for a specified page, which is clear from the description. However, it does not explicitly state when to use this tool versus alternatives (e.g., pbi_get_visual for a single visual), nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses a key limitation: 'Analisis lexico: detecta referencias escritas, no las construidas dinamicamente.' It also mentions returning broken references. This is valuable and goes beyond a simple statement of function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core question and then specify outputs and methodology. Every sentence adds substantive information without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a solid overview of functionality and limitations, and an output schema exists to cover return values. The main omission is the meaning of 'source', which is not clarified, but the description otherwise covers key aspects like transitive closure and broken references.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly explains 'depth' ('hasta depth') and implicitly covers 'name' (the measure to analyze), but the 'source' parameter is completely unexplained. With 0% schema coverage, this is a notable gap since the description must compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states its purpose: 'De que depende una medida y quien depende de ella' and enumerates specific output types (direct dependencies, broken references, transitive closure, reverse dependencies). This is a specific verb+resource+scope that distinguishes it from sibling tools like pbi_column_dependencies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for dependency analysis of measures but provides no explicit when-to-use or alternatives. It does not mention when to prefer this over pbi_column_dependencies or other analysis tools, leaving usage guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool corrects only fixable issues, respects margins, avoids moving correctly placed elements, and that dry_run=true returns the plan without writing. This provides useful behavioral insight, though it doesn't detail write side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. Each sentence provides distinct value: the core purpose, the specific corrections, the conservative principle, and the dry-run behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (page layout normalization) and the existence of an output schema, the description sufficiently covers the core behavior, including dry-run semantics. However, it could mention request_id or what happens when dry_run is false, though the output schema reduces the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for parameter meanings. It explains dry_run clearly ('dry_run=true devuelve el plan sin escribir') and page is self-evident from context, but request_id is never mentioned. This is partial compensation, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Corrige lo corregible de una pagina sin reacomodarla entera' (fix what's fixable on a page without rearranging it). It specifies the resource (a page) and the conservative approach, distinguishing it from siblings like pbi_align_visuals or pbi_normalize_report by emphasizing it doesn't move what's already fine.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this for conservative page-level corrections without full rearrangement. It does not explicitly name alternatives or provide when-not-to-use cases, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden, and it delivers strong behavioral specifics: what gets moved, what is scaled up, margin respect, no rearrangement of compliant items, and before/after audit score comparison. It does not mention persistence/reversibility or the role of the dry_run parameter, which is a notable gap for a mutation-capable 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences, immediately stating the main action, then providing key behavioral details. Every sentence adds value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does in terms of geometry normalization and audit score comparison, and an output schema exists to cover return values. However, it omits the meaning of the dry_run parameter and whether changes are persisted immediately, which is critical for safe usage. This makes it minimal for the tool's moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention dry_run or request_id at all. The dry_run parameter is especially important for understanding the tool's effect, but the description omits it. The parameter names are somewhat self-explanatory, but the description adds zero value to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool normalizes the geometry of ALL report pages, a specific verb+resource action. It describes concrete behaviors (containing overflow, scaling up too-small items, respecting margins) and distinguishes from the single-page sibling pbi_normalize_page_layout via 'TODAS las paginas.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use for whole-report layout normalization, while sibling tools handle single-page or other layout tasks. However, there are no explicit exclusions or direct alternative comparisons, so it lacks the explicit when-not-to-use guidance that would earn a 5.
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 no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool detects .SemanticModel and .Report folders, returns a summary with warnings, and marks the project as active. However, it does not disclose side effects (e.g., whether it modifies project files), failure modes, or permissions required. The 'marks as active' implies internal state change but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It leads with the main action, then explains what the tool detects and returns, and finally clarifies the parameter. Every sentence adds value without redundancy. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's core functionality: opening the project, marking it active, detecting TMDL/PBIR folders, and returning a warning summary. It provides an example warning, which is helpful. Since an output schema exists, it need not explain return values. It could mention how 'active project' affects subsequent tool calls, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a parameter name 'path' with no description, and schema coverage is 0%. The description compensates well by explicitly defining 'path' as 'ruta al archivo .pbip o a su carpeta' (path to the .pbip file or its folder), adding meaningful context about what values are acceptable. This goes beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary action ('Abre un proyecto .pbip' / opens a .pbip project) and a specific consequence ('lo marca como proyecto activo' / marks it as active). It also distinguishes itself from sibling tools like pbi_validate_pbip_project or pbi_backup_pbip_project by focusing on opening and activating the project, not validating or backing it up.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool should be used to open a project before working with it, as it marks the project as active. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The 'active project' concept hints at a workflow, but explicit guidance is missing.
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?
No annotations are provided, so the description carries full burden. It discloses that it accepts IDs or visible names and that unspecified pages retain their relative order at the end. However, it doesn't mention whether the operation is reversible, destructive, or has any prerequisites like an open project or permissions, which are common for mutation tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that deliver key information without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple reorder tool, the description covers the essential behavior: how pages are referenced and what happens to unmentioned pages. The tool has an output schema, so return values need not be explained. However, given the lack of annotations, some side-effect information would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for the 'order' parameter by stating it accepts IDs or visible names, which is helpful. However, it says nothing about 'request_id', leaving that parameter undocumented and adding no context for it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Fija el orden de las paginas del informe' (sets the order of report pages). It uses a specific verb and resource, and distinguishes it from sibling tools like rename_page, duplicate_page, and 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: it's for reordering pages. However, it doesn't explicitly mention when not to use it or alternative tools. Sibling tools exist for other page operations, so the purpose implicitly separates it, but no direct exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the dual mode (diagnose vs repair), validates the destination against the model before writing, and warns about the risk of guessing. However, it does not explain the `dry_run` parameter or potential side effects on reports, leaving some behavioral aspects opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and the second paragraph adds necessary detail about the mapping format and validation behavior. It could be slightly tighter, but it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core workflow (diagnose vs repair, mapping format, validation) but omits explanation of the `dry_run` parameter, which is critical for a write operation. The presence of an output schema reduces the need to describe return values, but the parameter gap prevents it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the `mapping` parameter with a concrete example (`{"Tabla[Viejo]": "Tabla[Nuevo]"}`) and clarifies that it triggers repair mode. However, `dry_run` and `request_id` are not described, and since schema description coverage is 0%, the description only partially compensates for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource+scope: 'Detecta referencias rotas en los visuales y las repara' (detects broken references in visuals and repairs them). This clearly distinguishes it from sibling tools like pbi_replace_visual_field, which handles direct field replacement, while this tool targets broken references. The name reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use the tool and what to provide: without `mapping` it only diagnoses, with `mapping` it repairs, and it warns against autonomous guessing. This gives clear context for usage, though it does not mention alternative tools or explicit 'when not to use' scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It indicates a trivial query is executed, which implies a lightweight, likely read-only operation. However, it does not explicitly state side effects, failure behavior, or prerequisites (e.g., a selected model), leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that delivers the core message without any fluff. It is front-loaded and entirely relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter connection test, the description is adequately complete. It states the action (validates connection) and method (trivial query). The presence of an output schema covers return values, so the description does not need to elaborate further. It could mention that a model must be active, but this is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already provides complete coverage. The description adds no parameter details, but the baseline of 4 applies because there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: validating the connection to the active model using a trivial query. It uses a specific verb ('Valida') and resource ('conexion al modelo activo'), and the method ('consulta trivial') distinguishes it from broader tools like pbi_health_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used to test connectivity to the active model, but it does not explicitly state when to use it versus alternatives such as pbi_health_check or pbi_session_info. There is no direct guidance on when-not-to-use or alternatives, so the usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses transactional atomicity, the four possible outcomes, preservation of page and visual IDs on update, the conservative default of merge mode (to prevent accidental deletion), and that dry_run writes nothing and returns a plan token. It does not mention permissions, conflict handling details, or side effects beyond the core behavior, but overall it is substantially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a lead sentence, a clear list of outcomes, and separate paragraphs for page, sync_mode, and dry_run. It is somewhat longer than necessary but every sentence adds value, and code formatting improves readability. It is front-loaded with the primary action and transactional guarantee.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, nested spec, multiple modes, and outcomes), the description covers the essential behavioral and workflow context. It explains the dry_run → pbi_apply_plan flow, which is crucial for safe usage. It omits details about seed and request_id, but those are likely auxiliary; an output schema exists, so return values are not needed in the description. Overall, it is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides meaningful semantics for page (id or visible name, defaults to spec name, preserves IDs), sync_mode (merge vs replace with conservative default), and dry_run (plan token). However, the central 'spec' parameter is not explained beyond 'el spec', and 'seed' and 'request_id' are completely undefined. While the covered parameters are important, the most critical input lacks any structural guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Materializa el spec como una pagina PBIR' (materialize the spec as a PBIR page), and adds a critical qualifier 'en UNA transaccion' (in one transaction). It further distinguishes itself from sibling tools like pbi_create_page_from_spec by listing four explicit outcomes (create, update, no_change, conflict), clarifying that it handles existing pages idempotently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: it applies a page spec to a PBIR page, with outcomes based on existence and change. It gives guidance on sync_mode (merge vs replace) and dry_run, explaining their purposes. However, it does not explicitly name alternative tools or say 'use this instead of X', so it misses the full when-not-to-use clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the concrete side effect: disabling will cause Power BI to remove automatic date tables (LocalDateTable_*) on reopening the .pbip. With no annotations provided, this behavioral info is essential and well-stated, though it doesn't mention reversibility or exact timing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences clearly deliver the key information without redundancy. The structure front-loads the main action and then adds context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle tool, the description provides the essential context: what it does, when it applies, and a key side effect. The existence of an output schema reduces the need to document return values; the main gap is the undocumented 'request_id' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only indirectly explains 'enabled' via 'Activa/desactiva', and does not mention 'request_id' at all. Since schema has no descriptions (0% coverage), the description should compensate for both parameters but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Activa/desactiva' with a clear resource 'Auto fecha y hora' and scope 'solo modo pbip'. It clearly labels the tool's function and distinguishes it from sibling tools focused on model queries and report edits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The text explains the benefit of disabling ('aligera el modelo') and prerequisite ('Requiere proyecto .pbip activo'), plus limitation 'solo modo pbip'. It does not explicitly name alternatives, but provides sufficient context for when to use this tool.
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 no annotations, the description carries the burden. It adds useful context about what 'pending' means and how only_pending=false changes output, but does not explicitly state that it is a read-only operation, nor does it mention any side effects, permissions, or error behavior. Some transparency is provided, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-line purpose, a clarifying definition of pending, and the parameter effect. Every sentence adds value, no fluff, and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with a single parameter and an output schema, the description is largely complete. It defines key terminology and explains the parameter. It could additionally mention that it is a read-only operation or point to related recovery tools, but these are not essential for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description directly explains the only_pending parameter: 'only_pending=false lists also the closed ones'. This fully compensates for the schema's lack of description, adding meaning beyond the raw boolean type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists journals of the active project, and specifies 'pending' journals as those from operations that were neither confirmed nor reverted. This distinguishes it from siblings like pbi_inspect_journal (inspect one journal) and pbi_recover_from_journal (recover from a journal).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the semantics of pending journals and the parameter effect, implying usage for checking stuck operations. However, it does not explicitly mention when to use this over alternatives like pbi_inspect_journal or pbi_recover_from_journal, nor does it give exclusions. Usage is implied but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly warns that the tool is destructive, explains the dry-run behavior without 'confirm', defines the exact scope (only manifest.json directories, never loose files, symlinks, or broad roots), and states that pending journals are always preserved. This is rich, safety-critical 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it starts with the purpose, immediately flags destructiveness, then details safe execution and safeguards. Every sentence adds value, and there is no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description effectively covers the critical safety aspects and the dry-run return behavior (manifest). The presence of an output schema handles return value details, so the description is quite complete for a destructive tool. However, the lack of parameter explanations for 'days' and 'max_journals' is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explicitly explains the 'confirm' parameter (dry-run when false) but does not clarify 'days', 'max_journals', or 'request_id'. This leaves most parameters undocumented and the agent guessing at their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Aplica la politica de retencion a los backups' (applies retention policy to backups), which clearly states the tool's verb and resource. It distinguishes itself from sibling tools by emphasizing the destructive nature and specific scope (only journal directories), setting it apart from backup creation or recovery 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cleanup via retention policy but does not explicitly state when to use this tool versus alternatives. It provides a safety guideline (without 'confirm' it returns a manifest) but no explicit 'use when' or 'instead of' instructions, leaving the agent to infer the appropriate 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?
No annotations are provided, so the description carries the full burden. It discloses partial update semantics and the mode restriction, which is valuable. It does not mention error conditions or prerequisites, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the tool's purpose, followed by the mode caveat. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and no schema descriptions or annotations, the description covers the essential update behavior and mode constraints but lacks details on prerequisites, error handling, and the purpose of 'request_id'. The output schema mitigates concerns about return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'mode' in depth and implies null/omitted fields are preserved, which directly informs optional parameters. However, it leaves 'request_id' unexplained and treats 'table' and 'name' as obvious identifiers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing measure ('Actualiza una medida existente') and adds the key nuance that unspecified fields are preserved. This distinguishes it from pbi_create_measure and pbi_delete_measure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on mode selection, explaining that 'both' is temporarily disabled and why, then instructing to choose 'live' or 'pbip'. While it does not explicitly compare with alternative tools, the use case for updating an existing measure is obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it explains that each action is executed via its own safe path ('transaccion, verificacion y rollback'), that failures are reported without stopping other actions, and that errors are not hidden. This goes beyond the schema and gives the agent important expectations about side effects and failure handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, with two short sentences that front-load the purpose and then provide essential requirements and behavioral details. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values. It covers the tool's purpose, a mandatory flag, and critical runtime behavior. It omits details about the nature of actions and the request_id parameter, but the overall context is sufficient for a moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameter descriptions, so the description must compensate. It partially does: it defines 'actions' as the ones from pbi_plan_audit_fixes and clarifies that 'confirm' must be true. However, it does not explain 'request_id' or the structure of items in the actions array, so the compensation is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Aplica las acciones devueltas por pbi_plan_audit_fixes' (Applies the actions returned by pbi_plan_audit_fixes). It uses a specific verb ('aplica') and names the exact resource (actions from the plan tool), which distinguishes it from sibling tools like pbi_plan_audit_fixes and pbi_apply_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear context by referencing the planning step that produces the actions, and imposes a critical precondition: 'Requiere confirm=true'. It does not explicitly mention alternatives or exclusions, but the reference to the plan tool makes the intended workflow (plan first, then apply) obvious.
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 no annotations, the description carries the full behavioral transparency burden. It discloses the specific audit checks (empty pages, untitled visuals, broken fields, duplicates, canvas sizes, page geometry) and scope exclusions, but it does not explicitly state whether the operation is read-only or mention any prerequisites or side effects. The word 'audita' implies read-only but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences. The first sentence states the main action and key exclusion; the second sentence efficiently enumerates the covered audit areas. No redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and a reported output schema, the description adequately defines the tool's scope and the specific checks it performs. It is slightly incomplete because it does not mention prerequisites such as whether a PBIR report must be open or connected, but this is minor and likely covered by the broader tool context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, so there is no parameter semantics to explain. The baseline for zero parameters is 4, and the description correctly does not attempt to describe parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Audita solo el informe PBIR' (audit only the PBIR report). It explicitly excludes semantic model rules, distinguishing it from model-focused audit siblings like pbi_audit_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'solo' and 'sin las reglas del modelo semantico' provide clear context that this is for report-only auditing, not model auditing. However, it does not explicitly name alternative tools or elaborate on when-not-to-use conditions beyond the semantic model exclusion.
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 no annotations, the description carries full burden. It explains the comparison outputs (tables/measures only on one side, DAX differences) but does not explicitly state that it is read-only or non-destructive. Given 'compare' implies no mutation, this is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main action and followed by the use case and output highlights. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, zero parameters, and presence of an output schema, the description adequately covers the essential behavior. It explains what is compared and what kinds of differences are reported, which is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides complete coverage. The description correctly focuses on behavior rather than parameters. Baseline for zero parameters is 4, and no further parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'compare' with a clear resource distinction: the live model versus the TMDL on disk. It clearly distinguishes from sibling tools like audit functions by stating it detects in-memory unsaved changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states a primary use case ('to know if there are unsaved changes in memory'), which gives clear context for when to use it. It does not exclude alternatives, but the context is sufficient for most agents to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It clearly warns 'Operacion destructiva' and mandates confirm=true, and it explains the constraints of mode='both' and the live/pbip prerequisites. This is substantive disclosure, though it stops short of detailing consequences like dependency breakage or irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it front-loads the purpose and safety warning, then explains the mode restriction in a compact way. Every sentence adds necessary context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, output schema present), the description covers the essential aspects: deletion, confirmation requirement, and mode selection. The output schema covers return values, so those are not needed in the description. It is sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It does explain 'confirm' and 'mode' in detail, but table, name, and request_id are left to inference from their names. This partial compensation is adequate but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Elimina una medida' (Deletes a measure), a specific verb and resource that clearly identifies the tool's function. It further distinguishes it from siblings like pbi_create_measure and pbi_update_measure, and clarifies destructive behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear operational context: it is destructive and requires confirm=true. It also explains the mode parameter explicitly, noting that mode='both' is disabled and advising users to choose 'live' or 'pbip' based on Power BI Desktop state. However, it does not explicitly compare this tool to alternatives like pbi_update_measure.
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?
Since no annotations are provided, the description carries the burden of disclosure. It explicitly states 'Solo lectura' (read-only) and clarifies that each finding includes geometric evidence, which informs expected output. It does not discuss error handling or performance, but for a read-only diagnostic this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs: the first states the purpose and read-only nature, the second enumerates specific detected issues and evidence. Every sentence contributes value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single optional parameter, an output schema, and no annotations, the description covers the tool's purpose, scope, non-destructive nature, and the types of findings. It could go deeper on parameter formatting, but the current level is adequate for a straightforward diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the 'page' parameter (0% coverage). The description's phrase 'de una pagina (o de todas)' explains that the optional page parameter targets a specific page or all pages when omitted/null, adding meaningful semantics beyond the schema's bare type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Diagnostica' (diagnoses) and resource 'geometria de una pagina' while listing concrete issues (solapamientos, visuales fuera del lienzo, etc.). It clearly differentiates from sibling tools that modify or document layout, making its diagnostic role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The read-only nature and scope ('una pagina o de todas') imply when to use it, but it does not explicitly state when to choose this over other layout tools like pbi_normalize_page_layout or pbi_audit_report_only. No exclusions or alternatives are mentioned, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the output location (outputs/), format (Markdown), and the composition of the document (model details, page-by-page visuals, audit scores). This gives the agent a clear picture of what the tool produces and where it writes, though it does not explicitly mention read-only behavior or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main purpose and output location, then lists the informative components. Every sentence adds value and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (which covers return values), the description supplies important contextual details about the document's structure and storage location. It sufficiently explains what the tool does and what is included, making it complete enough for a zero-parameter documentation generator. Minor gaps like the exact meaning of 'dominio' are acceptable given the output schema likely clarifies them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds context about what the generated documentation contains, which is relevant for the tool's operation even though there are no parameters to explain. No further parameter-level detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool produces complete technical documentation in Markdown saved to outputs/. It enumerates specific content: model (tables, measures with DAX and dependencies), report page-by-page with visual fields, and audit scores by domain. This distinguishes it from sibling tools like pbi_document_model (model-only) and pbi_audit_* (audit-only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when comprehensive documentation is needed—combining model, report, and audit—but does not explicitly mention alternatives or when-not-to-use scenarios. It lacks a clear comparison to related siblings such as pbi_document_model or pbi_audit_report_only, so usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the localhost port scanning mechanism and the specific return data, which gives a clear behavioral picture. It doesn't mention prerequisites or error behavior, but as a read-only discovery tool, it is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with the main verb upfront. Every clause adds information: scope (open local models), mechanism (AS engine detection), and output (port, connection string, catalog, table count). No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature, no annotations, and an output schema present, the description covers the essential context. It could mention that Power BI Desktop must be running, but 'abiertos localmente' implies that. The return values are described, and the output schema handles structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the baseline is 4. The description adds context about what the tool yields, making the zero-parameter interface self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists open Power BI Desktop models and specifies the mechanism (detects AS engine via localhost) and return fields (port, connection string, catalog, table count). This differentiates it from sibling tools that list tables or measures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (enumerate locally open models) but provides no explicit guidance on when to prefer this over alternatives like pbi_select_model or pbi_list_tables. No exclusions or alternative tool references.
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?
No annotations are provided, so the description must carry the burden. It states the output fields and the active report scope, but does not explicitly confirm read-only behavior, potential errors, or behavior when no report is active. This is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Spanish that is front-loaded with the verb and clearly conveys the purpose and output. No filler or unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless list tool with an output schema, the description covers the essentials: what it lists and what fields are returned. It could be more explicit about edge cases, but the scope is well-defined and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds contextual meaning about the implicit 'active report' state, but there are no parameter details to elaborate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lista' (lists) and the resource 'paginas del informe PBIR activo' (pages of the active PBIR report), and enumerates the returned fields (id, name, size, number of visuals). This distinguishes it from sibling tools like pbi_list_tables or pbi_list_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is used to list pages of the active report. It does not explicitly mention alternatives or exclusions, but the specific scope leaves little ambiguity about when 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?
No annotations are provided, so the description must carry the full burden. It describes what the tool returns (model, visual catalog, canvas, pages) and implies a read-only informational role, but it does not explicitly state that it makes no modifications, nor does it mention any side effects or prerequisites. This is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first lists what the tool delivers, the second gives usage guidance. It is front-loaded, concise, and every sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter information tool with an output schema, the description is mostly complete. It covers the tool's purpose, contents, and usage timing. It does not elaborate on the structure of the output, but the output schema likely covers that. Minor gaps: it does not mention whether the tool requires an active model or connection, but overall it provides enough context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds no parameter-specific semantics because there are no parameters to explain. It effectively communicates that the tool requires no input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Entrega el material para diseniar una hoja' (delivers the material to design a page), and enumerates its contents (model, visual catalog, canvas, pages). This distinguishes it from siblings that focus on individual aspects (e.g., list_tables, list_visuals) by providing a combined building-blocks view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use: 'Usa esto ANTES de proponer una hoja' (use this BEFORE proposing a page), and explains the benefit: 'te dice que campos y tipos de visual hay' (it tells you what fields and visual types exist). It does not mention exclusions or alternatives, but the timing guidance is clear.
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 no annotations, the description carries the burden. It discloses that the tool returns status and duration and reports credential/source errors. However, it does not elaborate on the side effects of clear_values or potential long-running behavior, leaving some behavioral aspects unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose, followed by clear parameter explanations. No redundant or filler content; each sentence contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to detail return values, but it still mentions status/duration. It covers core aspects such as the local model scope, types, table filtering, and error reporting. It could add prerequisites (e.g., a model must be open), but it is sufficiently complete for a refresh tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description must compensate. It explains the 'type' parameter with its allowed values and the 'tables' parameter with its optional semantics. The 'request_id' parameter is not explained, but it is generic and less critical, so the description adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool refreshes the local Power BI Desktop model, not the Service, using the verb 'Refresca' and specifying the resource. It also enumerates the refresh types, making the purpose explicit and distinct from siblings that handle other model 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it targets the local open model in Power BI Desktop and explicitly excludes the Service, which is a when-not condition. It also explains the parameters type and tables with their meanings, though it does not name alternative tools or explicitly state when to choose this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior. It clarifies what the tool reports (active model, project, freshness) and the meaning of stale versus mismatch, which goes beyond a simple label. It does not explicitly state that the tool is read-only, but the word 'Detalle' (detail) and the nature of the tool strongly imply it is an informational query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using two short sentences that front-load the core purpose and then add a clarifying distinction. Every sentence provides meaningful information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter information tool with an output schema, the description is fairly complete: it explains what session details are included and the status categories. The only gap is the absence of explicit guidance on when to run this check, but the low complexity and existing output schema mean the description does not need to over-explain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema contains no properties and the description does not need to explain parameter semantics. The description adds useful context about what the tool reports, even though it does not mention parameters because there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides session details (active model, active project, freshness) and distinguishes valid, stale, and mismatched sessions. It names a specific resource and the unique value it provides, which sets it apart from sibling tools that focus on model operations or project actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to check whether the current session is valid, stale, or mismatched, which is useful context for deciding whether to proceed with other operations. However, it does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria, so the guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains a key behavioral constraint (mode='both' is temporarily disabled and would apply only one destination) and prerequisites for live/pbip modes. It does not cover potential side effects or persistence, but the essential behavioral caveat is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two focused sentences. The first sentence states purpose with an example, and the second delivers critical mode constraints. No filler or repeated schema information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and an output schema, the description covers the essential points: what it does, the key mode limitation, and prerequisites. The output schema handles return values, so further detail is not expected. The description is complete enough for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It thoroughly explains the 'mode' parameter (values live/pbip/both and their conditions), and 'hidden' is implicitly covered by 'oculta o muestra'. 'Table' and 'column' are contextually understandable from 'una columna del modelo'. However, 'request_id' is not mentioned, so not all parameters are fully addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Oculta o muestra una columna del modelo' (hides or shows a model column), with a concrete example. It is specific in verb and resource, but it does not explicitly distinguish from sibling tools like pbi_hide_columns, though the singular 'una columna' implies a single-column operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on mode selection: it explains that mode='both' is disabled, that 'live' requires Power BI Desktop open, and 'pbip' requires it closed, telling the user to choose one. However, it does not mention when to prefer this tool over alternatives such as pbi_hide_columns, so no explicit exclusions are given.
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?
No annotations provided, so description carries full burden. It explicitly discloses destructive nature, confirm requirement, and refusal to delete last page, which are key behavioral traits. It also notes side effects on order and active page.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler; main action and critical warning are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool, the description covers the essential constraints and side effects. Output schema covers return values, so missing return details are acceptable. Could mention irreversibility explicitly but 'destructiva' implies it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 3 params with 0% description coverage. The description only clarifies confirm's role, leaving page and request_id semantics mostly unexplained. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 updates order/active page, using a specific verb and resource. It distinguishes from sibling tools like rename or reorder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context that deletion is destructive, requires confirm=true, and cannot delete the last page. However, it doesn't explicitly contrast with alternative tools, so it's clear but lacks 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?
With no annotations, the description must disclose behavior itself. It reveals that requesting `formats` writes markdown/html reports into `outputs/` and returns their paths, and it enumerates the analysis payload. It does not state whether the audit is strictly read-only or which project scope is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, dense lines front-loaded with the main purpose; no filler. Every sentence adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema and many siblings, the description covers purpose, scoping parameters, and the file-writing side effect. It would benefit from stating prerequisites such as an open PBIP project or selected model, but it is otherwise reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no descriptions (0% coverage), so the description's mention of `formats`, `rules`, and `min_severity` adds necessary meaning. It tells the agent that formats triggers file output and that rules/min_severity constrain the audit, though it omits possible values for `min_severity` and exact rule identifiers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a comprehensive audit covering 'modelo semantico + informe + layout' and lists concrete deliverables (global/per-domain scores, executive summary, prioritized findings, autofixable rules). This clearly differentiates it from sibling tools like pbi_audit_model or pbi_audit_report_only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage when a whole-project audit is needed, and mentions that `rules` and `min_severity` can scope the audit. However, it does not explicitly state when to prefer it over alternatives or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states 'Solo lectura' (read-only), which is a key non-destructive trait. It also discloses the scope of the check (dependencies, DLLs, session, project) and mentions specific attention flags like obsolete sessions and pending journals, providing useful context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using two compact paragraphs. The first sentence states the core purpose, and the second elaborates on usage and outcome. Every sentence contributes meaningful information without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a read-only health check with no parameters and an output schema already provided, so the description does not need to explain return values. It effectively covers purpose, usage timing, and key behavioral traits. It could be slightly more detailed about potential error conditions, but overall it is complete for a health-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to explain. The baseline score of 4 applies because the description inherently cannot add parameter-level value when no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Estado general del servidor: dependencias, DLLs, sesion y proyecto' (general server status: dependencies, DLLs, session, and project). It is specific and distinguishes itself from siblings like pbi_session_info (session only) and pbi_test_connection (connection test) by covering the overall health of the live environment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Es lo primero que conviene llamar' (it's the first thing you should call), and explains what information it conveys (live layer availability, open .pbip project, items requiring attention). It does not explicitly name alternatives or say when not to use it, but the context strongly implies its role as an initial health check.
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?
No annotations are provided, so the description carries the full burden. It discloses a critical dependency ('Requiere la capa EN VIVO'), explains the reason, and states the edge-case behavior for empty results ('devuelve una lista vacia con la explicacion'). This is useful 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, one for the critical requirement, one for edge-case behavior. Each sentence provides new information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema, the description covers the purpose, key constraint (live layer), and empty-list behavior. It is sufficient for an agent to know when and how to invoke it, though it could benefit from a brief note on what perspectives are.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by explaining that the live layer is required, which directly ties to the 'source' parameter (default 'live'). It does not explicitly document parameter values, but the context makes the intended usage clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lista las perspectivas del modelo' (lists the model perspectives), using a specific verb and resource. It also notes the live-layer requirement, which distinguishes it from sibling tools like pbi_list_tables or pbi_list_measures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies when to use this tool: when needing perspectives and working with the live layer, since 'el lector TMDL de este proyecto no las extrae' (the TMDL reader does not extract them). This implies an alternative approach is not viable for perspectives. No explicit exclusions are named, 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?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: the tool writes nothing (safe, non-destructive). It also states that it returns the exact actions that would be applied with their reasons. It does not cover other traits like authentication or error behavior, but the core safety aspect is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using three short sentences to convey purpose, safety, and parameter usage. It front-loads the most important information (plans fixes, writes nothing) and contains no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a moderate complexity, an output schema, and no annotations, the description covers the essential points: what it does, that it doesn't modify, that rules are required, and that objects narrows. It could mention the source of valid rule IDs (e.g., from audit results or pbi_list_audit_rules), but the output schema already documents the return format, so the description is sufficiently complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains that `rules` must be explicitly indicated (no implicit 'fix all') and that `objects` narrows to visual/page IDs. This adds meaningful semantic context beyond the schema's bare type definitions, though it does not specify where to obtain valid rule IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it plans corrections for specific rules ('Planifica correcciones para reglas CONCRETAS') and explicitly says it does not write anything ('No escribe nada'). This distinguishes it from the sibling tool pbi_apply_audit_fixes and clearly implies a planning/preview verb+resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: there is no 'fix everything'–the `rules` parameter must be explicitly provided, and `objects` narrows the scope further. It implies this tool is for planning before applying, but it does not explicitly name alternative tools or state when to use it vs. them.
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?
No annotations are present, so the description must disclose behavior. It explicitly states the tool does not modify the .pbip and returns the HTML path, which covers safety and output. However, it omits details like where the HTML file is saved or whether it cleans up artifacts, so transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences covering purpose, non-destructive behavior, the spec shape, and the return value. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one nested parameter and an output schema available. The description covers purpose, spec structure, and the output path, which is sufficient for a preview tool. Potential prerequisites or error handling are not mentioned but are likely minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'spec' as an object with additionalProperties true, providing zero field descriptions. The description compensates with a concrete spec template listing page_name, canvas, layout, and visuals with their subfields, giving essential structure to an otherwise opaque parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an HTML mockup of a proposed page, with a specific verb and resource. It also notes that it does not write to the .pbip, distinguishing it from apply/create 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use it to review a design in a browser before committing. It does not explicitly name alternatives or exclusions beyond the 'no write to .pbip' hint, so it falls short of a full when/when-not explanation.
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?
Despite no annotations, the description discloses critical behavioral traits: it validates the destination against the model before writing, rejects invalid/ambiguous/wrong-type references with 'field_not_found', and fails loudly if old_ref is missing rather than silently doing nothing. This goes beyond the schema and provides agent-essential error handling 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with the main action stated first, then parameter format, then behavior on failure. Every sentence conveys necessary information without redundancy, and the code-block formatting for parameter format improves readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity tool with no annotations, the description covers the essential usage, parameter syntax, validation, and failure modes. It does rely on the output schema for return values, but the description alone is sufficient to know how to invoke it correctly. Minor gap: it doesn't mention any effects on the visual's data or layout, but that's beyond scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions, but the description explains the format and semantics of old_ref/new_ref ('Tabla[Campo]' or '[Medida]'), clarifies that only existing projections are used, and explains validation behavior. It doesn't describe page/visual_id explicitly, but those are straightforward. Given 0% schema coverage, this adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Sustituye una referencia de campo dentro de un visual' (replaces a field reference within a visual), identifying the specific verb (replace), resource (visual), and scope (field reference). It distinguishes itself from sibling visual tools (like set_visual_title, delete_visual) by focusing on field reference replacement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that it works on existing projections and does not create new roles, implying it is for modifying existing field references rather than adding new ones. It also states it fails if old_ref is not referenced, giving a clear precondition. However, it does not explicitly name alternatives or when-not-to-use cases, so it's not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral transparency. It discloses a non-obvious behavior: visuals not included in the order are placed on top while preserving their relative order. It does not mention error handling or prerequisites, but it explains the core ordering algorithm sufficiently 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences in Spanish. It front-loads the primary purpose and then delivers critical parameter semantics. Every sentence earns its place, with no wasted words or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no annotations, and an output schema, the description covers the essential behavioral and parameter details. It explains the non-trivial ordering rules and unmentioned visual behavior, making it sufficient for correct invocation. Minor gaps remain (e.g., page identifier format, output specifics), but the output schema likely covers return values, and the description is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It provides detailed semantics for the 'order' parameter, explaining that IDs go from lowest to highest z and that the last one ends up on top. It also explains the behavior for unmentioned visuals. However, the 'page' parameter is not further clarified beyond being a page reference, leaving ambiguity about whether it expects a name or ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Fija el orden Z de los visuales de una pagina' (sets the Z order of visuals on a page). It uses a specific verb and resource, and distinguishes it from sibling tools like align/distribute/position, which handle spatial layout rather than layer stacking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for use: it defines the ordering semantics (least to greatest z, last on top) and how unmentioned visuals are handled (placed on top preserving relative order). It does not explicitly mention alternatives or when not to use it, but the specificity of the task makes the usage context 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?
With no annotations provided, the description carries the burden of explaining behavior. It discloses that the tool is an introspection/query tool that reports capabilities and reasons, and clarifies that it indicates whether writing is possible, not that it performs writes. It does not detail potential side effects, but the described nature makes side effects unlikely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core idea. Every sentence adds value: the first states the tool's function, the second provides usage guidance and specific capability areas. There is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an output schema present, the description needs only to explain the tool's role and what it reports, which it does thoroughly. It also gives essential context about when to invoke it, making it complete for an agent to decide to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no semantic value. The description compensates by explaining what the tool evaluates (live layer, .pbip writability, engine version capabilities), giving the agent enough context to understand the tool's scope without needing parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it reports what can be done 'right now' and what cannot, with the reason. It also gives a specific use case ('an agent should consult it before planning') which distinguishes it from sibling tools like pbi_health_check or pbi_session_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises when to use the tool ('before planning') and lists what it checks (live layer availability, write access to .pbip, engine-version-dependent capabilities). It does not mention exclusions or alternatives, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavioral traits: it warns of destructive operation, requires explicit confirmation, states that the previous definition is returned, and mentions that the journal allows restoration. This is comprehensive for a delete operation and goes beyond basic expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and includes critical safety and recovery information. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with an output schema, the description is sufficient. It covers the destructive action, the confirmation requirement, the return value, and the restoration mechanism. No other critical context is missing given the tool's simplicity and available structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 4 parameters with 0% description coverage. The description clarifies the crucial 'confirm' parameter by stating it must be true, which adds meaning. However, it does not explain 'page', 'visual_id', or 'request_id', though these are fairly self-explanatory from their names. It partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Elimina un visual' (deletes a visual), identifying the specific resource and distinguishing it from sibling tools like pbi_delete_measure and pbi_delete_page. The destructive nature is immediately highlighted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the tool is destructive and requires confirm=true, giving clear usage conditions. While it doesn't name alternative tools, the resource-specific 'visual' and the context of sibling delete tools make the intended use evident. No exclusions are mentioned, but the condition is useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and discloses that the tool does not apply anything ('sin aplicar nada'), which implies no side effects. It also explains the state fingerprint and the rejection behavior of pbi_apply_plan. This is substantive, though it stops short of fully describing all behavioral nuances like error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the primary purpose. It uses backticks and clear structure. No filler or redundant information — every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the plan contents (diff per file, state fingerprint), the rejection condition by pbi_apply_plan, and points to pbi_capabilities for operation enumeration. Since an output schema exists, return values are likely already documented. This is complete for an agent to understand when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by explaining that 'operation' must be one of those listed in pbi_capabilities under planned_operations, and 'arguments' matches what the target tool would accept. This gives the agent concrete guidance for both parameters, though examples would improve it further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Calcula un PLAN sin aplicar nada, y devuelve un plan_token' — it computes a plan without applying changes and returns a token. This distinguishes it from pbi_apply_plan, which is a sibling tool that would apply the plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description references pbi_apply_plan and explains that it will reject the plan if the project changes, implying this tool is for previewing/planning before applying. It also directs to pbi_capabilities for valid operations. However, it does not explicitly state when not to use it or compare with other planning tools like pbi_plan_audit_fixes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of disclosure. It details atomic validation ('si alguna tabla o columna no existe, no se modifica nada'), single-transaction writes (TMDL and SaveChanges), the meaning of count vs results, and the mode='both' behavioral restriction. This goes well beyond a minimal statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph plus one bullet-style line for the parameter, but every sentence carries meaningful information. It is not excessively long, though it could be split into clearer sections. The front-loaded purpose sentence is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 the description's own coverage of count/results, returns are adequately addressed. The description covers validation, transactionality, mode restrictions, and parameter format, making it sufficiently complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 0%, but the description documents the crucial `columns` parameter format (list of {"table": ..., "column": ...}) and explains the mode='both' restriction. It does not explain `hidden` or `request_id`, but hidden is self-explanatory and request_id likely internal, so the description substantially compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb: 'Oculta/muestra VARIAS columnas como un solo lote' (hide/show multiple columns as a single batch), specifying the resource (columns) and the batch operation. This distinguishes it from sibling pbi_set_column_visibility, which presumably operates on a single column.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the batch nature and gives important constraints: validation before writing, the transactionality, and the temporary disablement of mode='both' with instructions to choose 'live' or 'pbip'. However, it does not explicitly mention alternatives for single-column operations, so it lacks explicit differential guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description conveys key behavioral traits: it performs no restoration, operates read-only, and reports per-file status (unchanged, backup available, outcome). This is valuable transparency for a potentially destructive operation context, though it does not detail the exact 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and front-loaded: first sentence states the purpose, second clarifies safety and behavior, and the parameter note is concise. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only inspection tool with one parameter and an output schema, the description covers purpose, safety, behavioral details, and parameter source. It is complete in context, especially given the output schema handles return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'journal' is explicitly described as the path returned by pbi_list_pending_journals, providing crucial meaning beyond the bare string type in the schema. With 0% schema description coverage, this fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: inspects a journal and compares it with the current project state. It uses a specific verb ('inspects') and resource ('journal'), and explicitly notes it is read-only, distinguishing it from recovery tools like pbi_recover_from_journal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it should be used with a journal path from pbi_list_pending_journals, and it emphasizes read-only inspection before any recovery. It does not explicitly mention when not to use it, but the read-only note effectively differentiates it from recovery and purge tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the tool's read-only nature implicitly through 'resumen' (summary) and explicitly lists what it reports (broken references, relationships, etc.). It also explains the 'source' parameter options (live vs pbip), adding behavioral context beyond what a summary alone would imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. Each sentence adds value: the main summary statement, the enumerated contents, the usage recommendation, and the parameter clarification. No filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a model summary tool, the description is complete. It lists the key content areas (counts, table sizes, measures, calculated columns, disconnected tables, bidirectional relationships, broken references) and the source variants. Since an output schema exists, the description does not need to detail return values, and the provided information is sufficient for an agent to decide when and how to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a 'source' parameter with a title and default, but no description (schema coverage 0%). The tool description compensates fully by explaining the parameter's meaning and allowed values: "`source`: 'live' (Desktop abierto) o 'pbip' (archivos TMDL)." This is directly useful for parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it provides a compact model summary ("Resumen compacto del modelo") with specific content items (counts, table sizes, measures per table, calculated columns, etc.). This distinguishes it from sibling tools like pbi_list_tables or pbi_analyze_model_quality by framing it as an orientation-first overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using this tool first to orient oneself in a model ("Es la primera tool que conviene llamar para orientarse en un modelo"). It does not enumerate alternatives or exclusions, but the 'first tool' guidance provides clear context for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the destructive nature, conflict handling, byte-by-byte verification, and recreation of parent directories. It also explains the `recovery_conflict` rejection and `force_conflict` override, providing rich behavioral details beyond what any annotation could.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive. Each sentence adds valuable information: destructive warning, preview behavior, states, conflict handling, verification, and directory recreation. The front-loaded 'DESTRUCTIVA' immediately signals the most important trait. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations, the description covers all essential aspects: safety (destructive), preview, conflict states, force behavior, and post-restoration verification. With an output schema present, the lack of return format details is acceptable. The description is fully self-sufficient for an agent to understand when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning for key parameters: it explains that `confirm` toggles between preview and actual restoration, and `force_conflict` overrides conflicts. `journal` is self-evident from context. Only `request_id` is not explicitly described, but the overall compensation is strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'restaura' (restore) with a clear resource ('originales guardados en un journal'), and explicitly labels the operation as DESTRUCTIVA. This distinguishes it from sibling tools like pbi_inspect_journal (inspect) and pbi_purge_backups (purge), making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: without `confirm` it returns a preview, and with `confirm` it performs restoration. It also explains when `force_conflict` is relevant. However, it doesn't explicitly name alternatives or state when not to use this tool, so it stops short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing safety behavior. It clearly states the operation is a dry-run and does not modify the model, and it describes inter-measure references and return fields. However, it omits any potential limitations or prerequisites, so it falls short of a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with the core function, then usage guidance, then parameter details. It conveys essential information in three short lines with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested parameter and no annotations, but the description covers its purpose, safety, input structure, and output format. Since an output schema exists, detailed return value documentation is not required; however, it does not mention prerequisites like a selected model, leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is minimal (only an array of objects with additionalProperties), while the description fully specifies the expected structure: each object has 'name', 'dax', and optional 'table', and measures can reference each other. This completely compensates for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates DAX expressions of measures without modifying the model (dry-run with DEFINE MEASURE). It explicitly positions itself relative to pbi_create_measure, distinguishing its non-destructive validation purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly recommends using this tool before creating measures with pbi_create_measure, providing a clear alternative and when-to-use context. This gives direct, actionable guidance for an agent deciding between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses read-only behavior, the fail-closed policy, parameter effects (max_rows, max_bytes, timeout_seconds, export), the side effect of writing to outputs when export=true, the structure of the return value, and that DAX engine errors are passed through. This is comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using short paragraphs and bullet-like explanations. It front-loads the core purpose, then details constraints, parameters, and return values. Every sentence adds value—no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and an output schema, the description is complete. It covers all parameter semantics, the fail-closed query policy, the export side effect, and the return value composition. The presence of an output schema means the description needn't detail field types, but it still summarizes what is returned. No critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the purpose of max_rows (row limit), max_bytes (size cap to avoid returning megabytes), timeout_seconds (command timeout), and export (dump to outputs and return path). The query parameter is self-evident from the tool name. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'ejecuta una consulta DAX de SOLO LECTURA contra el modelo activo' (executes a read-only DAX query against the active model). It specifies the exact resource (DAX query, active model) and action (execute), and the allowed query forms (EVALUATE, DEFINE...EVALUATE, $SYSTEM DMVs) distinguish it from sibling tools that manage model metadata or make changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for running read-only DAX queries and enforces a fail-closed policy on accepted query forms. It explains that unsupported forms are rejected, which guides valid usage. However, it does not explicitly mention alternative tools for other tasks (e.g., listing tables or modifying measures), so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/pablo-horizun/horizun-pbi-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server