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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the agent knows this is a costly, non-repeatable generation. The description adds the input-ordering requirement (images are interpreted 'in order') and the option to omit the script for RoomLab's professional automatic tour, but says nothing about what gets consumed, cost, latency, or that omitting the script removes user control over the dialogue.

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?

Two sentences, with the use case front-loaded before the option list, and no filler. The second sentence leans on facts already encoded in the schema (durations, optional script), so it is slightly redundant rather than wasteful.

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?

With an output schema present and 80% parameter coverage, the definition needn't explain return values, and it covers the trigger, the image count, ordering and the two user-tunable options. It omits any mention of the additional_instructions parameter and gives no cue about which image parameter form to prefer, which leaves a small gap.

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 80% and the schema already documents the 3-6 image bounds, the 12/15/30 duration enum and the 12-second default, so the description's duration and script sentences largely restate structured data. Its one genuine addition is that image order defines tour order, which is not obvious from the array's description of 'attached in tour order'; nothing is said about choosing between the images and image_urls parameters.

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 names a specific verb and output ('cinematic tour made from...room images') plus the input cardinality, so an agent can tell this is a video-generating tool rather than an image edit. It stops short of explicitly distinguishing itself from the sibling create_video_walkthrough, which is the nearest neighbor an agent could confuse it with.

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?

'Use when the user wants a cinematic tour' gives a clear triggering condition, and the second sentence clarifies that a script and duration are user-controlled options rather than requirements. There is no when-not-to-use guidance and no named alternative for the walkthrough-vs-tour decision.

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