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

With no annotations, the description carries the behavioral burden. It discloses that this is a single POST request, that it retrieves status, and that the response is either JSON status or an MP4. It does not cover error cases, idempotency, or how the MP4 is delivered, but it gives the essential one-shot behavior.

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 a single telegraphic fragment with no wasted words: it gives the method, endpoint, invocation count, and expected response type. It is concise and front-loaded, though it could be slightly more natural as a full sentence.

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 simple single-parameter tool, the description covers the core call pattern and response categories. However, without an output schema it does not clarify under what conditions the caller gets JSON status versus an MP4, nor how the MP4 is returned, leaving some ambiguity for an agent.

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 only parameter, queue_id, is already fully described in the schema with 100% coverage. The tool description adds no additional parameter context, which is acceptable because the schema already provides sufficient meaning.

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 identifies the operation as a one-time POST to /v1/video/retrieve and indicates the outcome is either a JSON status or a delivered MP4. This is clear enough for the tool's purpose, but it does not explicitly distinguish it from sibling tools like video_retrieve or wait_for_video.

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 word 'once' implies this is a single status check rather than a polling/waiting operation, which offers some usage context. However, it does not explicitly say when to use this tool instead of wait_for_video or video_retrieve, nor does it state any exclusions.

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