aua_batch

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

Annotations only declare readOnlyHint=false, openWorldHint=true and idempotentHint=false, so the description carries real additional weight: full-plan validation before any action, the exact stop conditions (error, unmet condition, scroll miss, Enter submission, 25s budget), that in-flight RPCs may overrun the budget, and the resume/replay rule. That is exactly the operational context an agent needs before firing a mutation batch.

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?

Four dense sentences, front-loaded with scope and validation, followed by stop conditions and the resume rule. Almost no waste; the parenthetical about in-flight RPCs is the only borderline detail, and it is genuinely useful for timeout reasoning.

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?

No output schema exists, and the description only indirectly reveals a return field via 'Resume from stopped_at'; it does not describe per-step results or error payload shape. Given the tool's mutation stakes and 20-step plan complexity, that is a small but real gap; everything else an agent needs to call it safely is present.

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?

With schema description coverage at 0% and a nested args object that is schema-free (additionalProperties: true), the description compensates by explaining that args are 'each operation's normal args' - i.e., reuse the argument shape of the corresponding single-op tool. That resolves the biggest ambiguity, though it does not enumerate per-op required args.

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?

States a specific verb and resource, 'Execute up to 20 known steps', plus the key scope constraint that each operation uses its normal args. This clearly separates it from the single-operation siblings (aua_tap, aua_swipe, ...) as a batched executor, but it never names the planning alternative aua_execute_goal, so the differentiation is inferential rather than explicit.

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 gives operational guidance for one scenario - resuming from stopped_at and never replaying completed or uncertain steps - which implies it is meant for known, pre-determined plans. It does not state when to prefer this over aua_execute_goal or the individual action tools, so usage is only partially implied.

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