emu_list_operation_runs

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

With no annotations provided, the description carries the full disclosure burden, and all it offers is the word 'completed' — implying in-flight or queued runs are excluded from results. It doesn't state default behavior when no limit is given, whether results are ordered, or whether the filter means the tool tolerates no in-progress runs.

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 four words with zero waste — essentially the acceptable floor for a phrase. However, this reads more like under-specification than deliberate concision. Every word 'earns its place,' but there was room for more substance.

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 list tool with no output schema and no annotation coverage, the agent has no idea what an operation run looks like (structures, sections), how results are ordered, or how pagination works. The configuration of list vs. get vs. create is implied by the name but never stated.

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 coverage is 0% and the description never mentions 'limit' — its meaning, range, or default value. While the parameter name is reasonably self-explanatory, the description adds no semantic value beyond what the schema field name already implies, and doesn't compensate for the 0% coverage.

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 uses a specific verb ('List') with a clear resource ('operation runs') and a scope qualifier ('completed') that implies a filter. It reads distinctly from emu_get_operation_run (singular) and emu_create_operation_run structurally, though it never names those siblings explicitly.

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?

No guidance is given on when to use this tool versus emu_get_operation_run, emu_get_scenario_run, or emu_list_call_sessions. With over 70 siblings, including several other 'list' tools, the agent must infer the selection criteria entirely from naming conventions, which is error-prone.

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