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

Annotations already declare destructive=true and idempotent=true, and the description adds genuine context beyond them: cloud jobs wait on referenced batch outputs before submitting dependents, the call does not block on renders, and existing selected images are not replaced. It does not explain why the tool is flagged destructive (whether prior standalone media can be overwritten) or how request_key drives idempotency, leaving a gap against the destructive hint.

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?

Dense but front-loaded: the batch size, key uniqueness rule and intra-batch reference behavior come first, then the destination restriction, then the alternative tools. The last two sentences are slightly compressed run-ons ('This accepts all files/jobs together; it does not wait for renders...'), but no sentence is redundant.

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 six-parameter nested-object mutation with an output schema, the definition covers the async lifecycle, dependency ordering, defaults inheritance and the exclusion of element workflows – enough to call it correctly. The remaining hole is the provider-selection tradeoff and the meaning of the destructive flag, which no structured field supplies.

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 only 50% schema description coverage, the description compensates for the weak spots: unique local keys per image, reference_keys allowed to point at later entries in the same batch, folder_path creating or reusing a Media folder inline, and omission of unchanged settings to inherit Series defaults (implicitly aspect_ratio, image_quality, image_resolution). It says nothing about provider or provider_selection_reason, which the schema also leaves undocumented.

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 with scope: 'Submit 1–24 complete image prompts and their references in one request.' It also explicitly names the sibling workflows it does not cover (save_element_file, generate_element_take, edit_element_file_references), so an agent can distinguish it from generate_series_media and the element tools without opening a schema.

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?

Gives explicit routing: this batch accepts only destination=standalone_media for explicitly standalone content, while character/set/prop images must use save_element_file and generate_element_take followed by wait_for_jobs and read_element. Dependent-file edits are routed to edit_element_file_references, and the 'does not wait for renders' clause tells the agent it needs a polling step.

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