Extract time-coded dialogue and pauses from one video time window, downloading only that segment's audio for ASR when subtitles are unavailable; use it to check a short clip or sample long videos.
只看某个时间窗：该窗内的台词（带时间码）与停顿。 有缓存/平台字幕则零下载；否则只下该窗口的音频做 ASR，不转写全片。 方言可传 lang=yue / prompt=...。适合"刚才那 30 秒他说了什么"，也是长视频抽样的主力工具。
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | 60 | |
| url | Yes | ||
| lang | No | zh | |
| model | No | small | |
| start | No | 0 | |
| prompt | No |
Changes observed during successful MCP inspections.
v1.6.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, and it does disclose the operationally important trait: zero download when cache/platform subtitles exist, otherwise only that window's audio is fetched for ASR. That cost/latency profile is exactly what an agent needs to decide between this and a full run. It is silent on failure behavior for out-of-range windows and on output granularity beyond 'lines + pauses'.
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?
Front-loaded with the core purpose, then cost behavior, then parameters, then use cases — a sensible order in four tight lines. Minor redundancy between '只看某个时间窗' and '该窗内的台词', but nothing that wastes the reader's time.
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?
It usefully describes the return content (timecoded lines plus pauses) despite there being no output schema, and covers the caching tradeoff. But for a 6-parameter tool with zero annotation and zero schema-description coverage, leaving time-unit semantics and the model parameter unexplained means an agent still has to guess on invocation.
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% across 6 parameters, so the description must compensate. It does name lang (yue) and prompt, and implicitly defines start/end via the 'time window' framing, but it never states the accepted format or units for start/end — a real gap given the schema allows both string and number with string defaults ('0', '60'). The model parameter is entirely undocumented.
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-and-resource: 'only look at a time window' returning the lines in that window with timecodes plus pauses. It implicitly carves out a distinct scope from full-transcript siblings ('不转写全片'), so an agent can tell it apart from video_full/video_subs without opening schemas. It stops just short of naming the alternative tool explicitly.
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 concrete when-to-use guidance: '刚才那 30 秒他说了什么' and '长视频抽样的主力工具', plus the condition '方言可传 lang=yue'. It signals when not to use it ('不转写全片'), but never names the sibling tool an agent should pick for full transcription.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.