pbi_run_dax

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

Without annotations, the description carries the full burden of behavioral disclosure. It explicitly states the read-only nature, the fail-closed policy on supported query forms, the effects of max_rows, max_bytes, timeout_seconds, and the export side effect of dumping to outputs/. It also describes the return content (columns, types, rows, execution stats, truncation reason) and that DAX engine errors are returned as-is. This is thorough transparency.

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

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

The description is compact and information-dense, with no filler sentences. It is front-loaded with the core purpose, followed by constraints, parameter effects, and output summary. Each sentence earns its place, and the structure (separate lines for key sections) aids readability.

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

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

Given the tool's complexity (a DAX query executor with safety limits and export behavior), the description is complete. It covers the accepted query forms, the fail-closed policy, parameter semantics, side effects, and return structure. The presence of an output schema means detailed return format is not required in the description, but it still summarizes it. No significant information is missing.

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

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

Schema description coverage is 0%, but the description compensates fully. It explains the `query` parameter implicitly by specifying accepted forms (EVALUATE etc.), and explicitly defines `max_rows`, `max_bytes`, `timeout_seconds`, and `export=true`. Every parameter in the schema is accounted for, adding meaning beyond the raw type definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with a clear statement of purpose: 'Ejecuta una consulta DAX de SOLO LECTURA contra el modelo activo.' This identifies the specific verb (ejecuta), resource (consulta DAX), and scope (modelo activo), and explicitly marks it as read-only. It distinguishes itself from sibling tools like pbi_search_model or pbi_profile_data, which are not DAX query executors.

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

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

The description provides clear context for when to use the tool: it accepts only EVALUATE, DEFINE...EVALUATE, and $SYSTEM DMVs, and rejects everything else (fail-closed policy). It clarifies the operational boundary but does not explicitly name alternative tools or say when not to use it in favor of another. Since the tool name is self-explanatory and the constraints are explicit, this is a solid 4 rather than a 5.

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