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

Annotations already indicate this is a non-read action and non-destructive, but the description adds key behavioral details: the tool is billed, and it is asynchronous because it returns an audition_id immediately and requires polling of audition_status until ready. These are important traits not captured by the annotations alone, enhancing transparency beyond the structured data.

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 three declarative sentences, each with a distinct purpose: define the action, explain the async flow and return artifacts, and indicate where the actor_id comes from. It is front-loaded with the primary verb and noun, contains no filler, and every sentence earns its place by contributing essential operational or prerequisite information.

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?

Despite having no output schema, the description explicitly discloses that the tool returns an audition_id immediately and later provides a shareable video_url, covering the return value lifecycle. It also flags billing, which is critical for a paid action. While it doesn't mention failure modes or alternate casting_id paths, those are sufficiently explained in the schema, so the description covers the core transaction workflow.

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?

The schema has 100% description coverage, so the baseline is 3. The tool description itself only highlights 'cue' and 'actor_id' source, without adding new meaning to parameters such as casting_id, direction_notes, or batch_approved. Since the schema already documents all parameters sufficiently, the description's marginal contribution to parameter understanding is minimal, consistent with a 3.

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 the specific verb 'Start' and resource 'casting audition', and elaborates with a concrete summary: the actor performs a cue in a short vertical video. It distinguishes this from sibling tools like audition_status (which polls status) and revise_audition (which modifies) by focusing on the initiation action and the immediate billing implication.

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 for when to use this tool: to begin an audition. It includes operational workflow guidance ('Returns audition_id immediately; poll audition_status...') and points to a prerequisite ('Get actor_id from casting_roster'), but it does not explicitly enumerate exclusion criteria or compare with alternative audit tools beyond the workflow implication. That fits 'clear context, no exclusions'.

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