video_frames

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

No annotations are provided, so the description must carry the full burden. It usefully discloses two behavioral facts a schema cannot: a hard cap of 6 frames, and that frame extraction downloads the corresponding video segment and therefore costs more than video_sheet. It does not say how images are returned (format, whether resized by width), nor does it cover failure modes for out-of-range timestamps.

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 short sentences, with the core capability and its cap stated first, followed by the usage condition and the cost caveat. Every sentence carries information, and there is no padding.

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 3-parameter read tool with no annotations, no output schema, and no parameter descriptions, the description covers purpose, the cap, the return type at a high level, and relative cost. It still leaves the meaning and units of width, the format of the returned images, and the validation of 'at' unexplained, which matters given the 6-frame limit.

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 should compensate. It establishes the key semantic that frame positions are given in seconds ('按秒数'), which is not obvious from a bare 'at' array of numbers, and that the list is capped at 6. The url and width parameters are left entirely undocumented, so the compensation is only partial.

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?

States a specific verb+resource: extract frames at precise second offsets, capped at 6, returning the images themselves. This is meaningfully more specific than the bare name, though it does not distinguish itself from the related tools video_ocr or video_visual_scan, which also deal with reading visual content.

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?

"只在需要读小字/看清细节时用" gives an explicit condition for when to use this tool, and the note that it costs more than video_sheet names the cheaper alternative. It lacks an explicit "do not use for X" clause and does not address the overlap with video_ocr, so it stops 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.