pbi_run_dax

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.

Is 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.

Given 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.

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

Schema description coverage is 0%, so the description must compensate. It explains the 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.

Does 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.

Does 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.