generate_video

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

With no annotations, the description carries the full burden and it does disclose the key non-obvious traits: the 1–5 minute latency and the async fallback that returns an ID instead of a video. It also names the default model. It doesn't mention cost, rate limits, or what happens on generation failure, so it is not exhaustive.

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 purpose statement is front-loaded and the Args block is tight, with each parameter getting one useful line. The docstring-style parameter block repeats parameter names already in the schema, which is mild overhead, but the added semantics justify the space.

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 values needn't be spelled out, and the description covers the one behavioral quirk an agent must know: the ID-returning async path plus the pointer to check_video. For a three-parameter, one-required generation tool this is close to complete, missing only failure/cost expectations.

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 0%, so the description must compensate, and it does: prompt is documented with an example string and a language recommendation, image_url is explained as the first frame, and model is documented as owner/name format with a stated default (minimax/video-01). The only gap is that image_url doesn't state whether it must be publicly accessible or what sizes/formats are accepted.

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 opening sentence names a specific verb+resource ('Сгенерировать короткое видео по текстовому описанию') and adds the qualifier 'короткое', so the agent knows exactly what is produced. It is clearly distinguishable from check_video and download_video, and the final sentence explicitly routes to check_video for the polling step.

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 gives a clear usage context: generation takes 1–5 minutes, and if the video isn't ready the tool returns an ID that must then be passed to check_video. That is real when-to-use routing. It lacks explicit when-not-to-use guidance (e.g., cost, concurrent generation limits), so it falls short of a 5.

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