get_video_status

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

Annotations already declare readOnlyHint=true and openWorldHint=true, lowering the bar. The description adds meaningful context: polling cadence, the status enum values, a progress field, and the contents of the returned Video object. It doesn't cover rate limits or error/failure details beyond status='failed', but provides solid additional behavioral transparency.

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 slightly longer than the absolute minimum, but it is well-structured with a clear first sentence, a usage note, a return object breakdown, and a workflow. Every sentence adds value, and the bullet-like list in the workflow makes it easy to scan. A 5 would require even tighter wording while preserving all this useful content.

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?

Given that there is no output schema, the description fully explains the return values (status, progress, id, other metadata), the status enum, and the polling workflow. It also covers the tool's role in the broader lifecycle, making it complete enough for an agent to use correctly without external docs.

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 0%, so the description must compensate. It explains that video_id comes from create_video/remix_video and is used in the polling workflow, and also mentions it appears in the returned Video object as 'id'. This gives enough meaning beyond the schema's 'Video Id' label, though it doesn't explicitly format or validate the parameter.

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 explicitly states the tool checks 'status and progress of a video generation job', which is a specific verb+resource combination. It clearly distinguishes this from sibling tools like create_video, remix_video, and download_video by focusing on the polling/status aspect.

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 explicitly says to use this after calling create_video or remix_video, provides polling frequency ('every 5-10 seconds'), and outlines a typical workflow with steps. This gives clear when-to-use context and differentiates from alternatives.

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