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

Annotations already declare mutation, non-idempotence, and destructuring, but the description adds substantive context beyond them: the task is billable, backend validation is authoritative, no modes/models/voice choices are inferred or injected, legacy reference_images/reference_audio and flat model parameters are rejected, and the agent must never auto-resubmit after a rejection or unconfirmed submission. These are genuine operational constraints an agent would not derive from the annotations.

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 operative calling instructions are reasonably front-loaded in the first several sentences, but the latter half drifts into reply-presentation policy about hiding task_id, session_id, run_id, voice_id, and file IDs — useful context, yet verbose and loosely tied to invoking this specific tool. There is noticeable repetition around identifier retention.

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?

An output schema exists, so return-value documentation is not required, and the routing/identifier lifecycle is well covered. What is missing is the most basic thing an agent needs for this specific tool: that it produces images, and any hint about image-specific input expectations, cost per generation, or typical latency — so the description is complete on workflow mechanics but silent on tool-specific substance.

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 100%, so the baseline is 3. The description does add a few things the schema does not spell out as directly — that input must carry original model parameters with explicit file_bindings, that reference_files and direct URLs must not be mixed, and that legacy reference_images/reference_audio are not accepted — but the session_title/session_id/base_run_id semantics largely restate the parameter 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 opens with "Create one independent billable Studio task," which states a verb and a resource but never says what is actually generated (an image). It reads as generic boilerplate shared with generate_task, generate_video, generate_music, and generate_speech, so an agent has no textual basis for distinguishing this tool from its siblings beyond the tool name itself.

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?

It gives real workflow guidance: read list_models.defaults for the default model, read get_model_schema for the full schema, use session_title for a new topic, session_id to continue, and session_id plus base_run_id for a version. However, it never states when to choose generate_image over generate_video or generate_task, and offers no exclusions, so routing between creation siblings is left implicit.

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