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

With no annotations, the description carries the burden and does so well: it discloses local model execution (SenseVoice), that only the segment is downloaded (~0.5MB per 20s), that beat values are approximate, and that emotion/event outputs are model labels rather than facts. It omits cost/rate limits and response structure details beyond the label list.

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 compact and front-loads what the tool returns, then adds the download-scope and interpretation caveats. Each sentence contributes, though the caveat about beat estimation is slightly wordier than needed.

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 4-parameter tool with no output schema, the description conveys what the response contains and how to interpret it, which is the main thing an agent needs. The remaining gap is parameter-level detail (start/end/lang semantics), which is the only reason it is not a 5.

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 document url, start, end, and lang. It only hints at the segment concept and the 20-second default ('20 秒约 0.5MB'); start/end formats and especially the purpose of the lang parameter (default 'zh') are left completely unexplained.

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 gives a specific verb ('听一段' — sample a segment) and enumerates the outputs: SenseVoice language/emotion/audio events plus beat/energy. It also distinguishes itself from the transcription path by stating it '不转写全片', so an agent can separate it from video_subs/video_full, though it doesn't explicitly name those siblings.

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?

It gives clear conditions for when the tool is worthwhile (music or edit rhythm) and when it is not ('节拍估计对纯语音段意义有限'), which is real when/when-not guidance. It stops short of naming an alternative tool, so it is not a full 5.

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

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

With no annotations, the description carries the full burden and does well: it discloses subtitle-first sourcing (0 media download), ASR fallback only when subtitles are missing, truncation behavior on long videos, and context-cost warnings for full mode. Gaps remain on the undocumented flags (refresh, scan_cuts, model) and on whether results are cached or how errors surface.

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 default behavior and output shape, then cost warning, then source strategy, then fallbacks. Dense but each line carries operational information; only the duplicated full/level instruction is redundant.

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?

No output schema and no annotations, so the description must cover a lot for an 8-param tool. It adequately covers the main path (URL → digest/full) and the visual-follow-up split, but leaves refresh, scan_cuts, and model behavior unexplained for an agent to call those correctly.

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% across 8 params, so the description must compensate and only partly does: it explains full, level, lang, and prompt with concrete values/examples. model, refresh, and scan_cuts receive zero explanation, and the overlapping full=true vs level='full' wording creates mild ambiguity about which switch to use.

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 uses a specific verb+resource ('看一个视频') and defines the default deliverable precisely (章节 + 关键句 + 全文路径, ~1.5k 字) plus the alternate full-report mode. It distinguishes itself from video_sheet/video_frames, though several near-siblings (video_full, video_watch) are never differentiated.

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?

Explicit when-to and when-not guidance: default digest, use level='full' only when a full report is truly needed and it '长期占用上下文，慎用', long >20min no-subtitle videos stop at chapter suggestions unless full=true is passed. It also routes the agent elsewhere ('需要看画面再用 video_sheet / video_frames') and warns against a bad alternative ('不要下整片').

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

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

With zero annotations the description carries the full burden and mostly does: login-free access, Bilibili-only coverage, a hard cap of 4 images, and the reason images are off by default (base64 screenshots flooding the context window). It also discloses that all comments are sanitized and injection-scanned before display, which is genuinely useful trust context. It omits rate limits and what happens on unsupported platforms.

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-loads the capability and platform scope, then the image caveat with its rationale. Every sentence carries information; the parenthetical explanation of why images are excluded is slightly long but justifies a non-obvious default.

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?

No output schema and no annotations, yet the description enumerates the returned analytics and states the image-off default, so an agent knows what comes back. The remaining gap is input-side: URL format and limit semantics are necessary to call it correctly and are absent from both schema and description.

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 explain all three parameters. It explains with_images thoroughly (default false, max 4, context-blowout rationale) but says nothing about the required `url` format (full URL? BV id?) or about `limit` and its default of 40, leaving two of three params undocumented anywhere.

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: fetch the public comment section of a video, currently Bilibili-only and login-free, and enumerates the derived outputs (engagement ratio, sentiment word frequency, controversy heuristic, top comments). That clearly separates it from video_subs/video_meta/video_transcript siblings by resource, though it never names a sibling 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 a real conditional for with_images ('only pass with_images=true if you actually need the images'), plus the platform/authentication precondition. It gives no guidance on when to prefer this over video_brief or video_full, which also summarize a video, so routing between siblings is left to inference.

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

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.

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

No annotations, so the description carries the disclosure burden; it reveals the confirmation gate and that this is a heavyweight operation not needed for normal analysis, which is the key behavioral trait. It omits what happens on oversized/failed downloads and any cost or timeout implications of pulling a full file.

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?

Three short sentences, front-loaded with the action and its restriction, then the confirmation gate, then the sibling redirect. Nothing is wasted.

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?

With no annotations, no output schema, and 0% parameter coverage, the description should say more: max_mb semantics and default-bound behavior (what happens if the video exceeds 800 MB) are entirely absent, and there is no indication of return shape for a download operation.

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 all three parameters are bare. The description usefully explains that confirm must be True, but 'max_mb' (default 800) is never mentioned and 'url' is only implied, leaving part of the surface unaddressed.

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 ('下载整片' – download the full video) and immediately scopes it ('仅在你明确要看全片时使用'), distinguishing it from the sibling video_brief which handles ordinary analysis. An agent can select between the two without opening either schema.

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?

Explicitly names the alternative ('先试 video_brief') and the condition that selects this tool (only when the full video is genuinely needed), plus a hard precondition (confirm=True). When-to-use, when-not-to-use, and the gating requirement are all present.

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

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

With no annotations, the description carries the behavioral burden and does well: it discloses the blocking wait behavior, the client-timeout risk above 60 seconds, and the different return shapes for running vs. completed jobs. It does not cover error cases or what happens when the wait expires, but the core behavior is clear.

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 compact sentences with no filler; the practical wait_seconds constraint and the return behavior are front-loaded. It could be slightly more structured but wastes no words.

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 two-parameter polling tool with no annotations and no output schema, the description covers the essential behavior: blocking semantics, timeout risk, and the shape of returned data. The main omission is how to obtain job_id and any error/timeout behavior.

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 adds genuinely useful semantics for wait_seconds (recommended 20–30, hard practical limit 60 due to client timeout), but job_id is left completely unexplained—its format and origin from video_job_start are not stated.

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: querying a background job, with what it returns on completion vs. while running. However, it does not explicitly differentiate from the sibling video_job_start, so the agent must infer the relationship from names alone.

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?

Usage is implied by '查询后台任务' and the wait_seconds guidance, which signals this is a polling call after a job has been started. No explicit when-to-use or alternative-tool guidance is given, and video_job_start is never mentioned.

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

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 critical async behavior: this starts a background job and must be polled via video_job. It does not say what the start call returns (a job id?), how long jobs run, whether jobs are queued or concurrent, or what happens on failure — all material for an async mutation.

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-loads the problem it solves (client timeout) and then the routing advice in three tight lines. Dense but every clause carries operational meaning; no filler.

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 7-parameter asynchronous job with no annotations and no output schema, the description omits the return shape needed to actually use video_job polling (job id/handle), and leaves five parameters undocumented. Strong on routing, thin on everything needed to invoke and follow up correctly.

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 7 parameters, so the description must compensate, and it only explains two: full=true (verbatim extraction) and comments=True (adds comment-section controversy analysis). url, lang, model, prompt, and scan_cuts get no explanation anywhere.

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: start a background job for long videos to avoid client timeouts, then poll with video_job. That distinguishes it from the synchronous extraction siblings, though it never contrasts itself with video_full or video_watch, which look like the nearest overlapping tools.

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?

Explicitly prescribes an ordering (video_meta → video_plan → video_window / video_sheet) that defers this tool, and names the one condition that justifies it: only when a full verbatim transcript is actually wanted (full=true). It also names video_job as the required follow-up, so the agent knows the alternative and the condition.

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

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

With no annotations, the description does carry real behavioral weight: "不下载任何媒体，几乎零成本" tells the agent this is a side-effect-free, low-latency read. However, it does not cover failure modes for private/geo-blocked videos, rate limits, or whether any network cost exists beyond 'almost zero'.

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?

Three short clauses ordered well: what it returns, then the cost/side-effect guarantee, then the decision it supports. Zero filler and the returned-field list is front-loaded.

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?

There is no output schema, so the field enumeration in the description usefully doubles as the return-value contract. For a single-parameter read tool with no annotations, the only meaningful gap is the accepted URL format.

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% for the single `url` parameter, so the description must compensate; it only weakly does so via "公开视频", implying the URL must point at a publicly accessible video. No format examples (short link vs. full URL vs. BV id) are given.

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 concrete verb+resource: reads metadata of a public video, and enumerates the returned fields (title, uploader, duration, date, views/likes, subtitle presence). This field list effectively distinguishes it from siblings like video_subs or video_full, though it never names them 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?

"用于判断这个视频值不值得看" implies a usage context (cheap pre-check before committing to heavier tools), but there is no explicit when-not guidance and no sibling is named as the alternative. An agent must infer that this is the triage step before video_full/video_watch.

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

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

With no annotations, the description carries the full burden and does so: it discloses that it downloads only the lowest-quality segment, that cost is ~0.3–0.8s per frame on CPU, that the OCR engine is a ~80MB optional dependency, and exactly what install=false vs install=true do. This is unusually rich operational context.

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-loads the core action and the trigger condition, then cost, then the install caveat — a sensible order. Markdown emphasis and quoted phrasing add some visual noise, but no sentence is filler.

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 6-parameter tool with no output schema and no annotations, it covers purpose, trigger, cost, dependency handling, and that results carry timecodes. Only the width parameter and the exact result shape (beyond 'timecoded, directly quotable') are left unexplained.

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 explains n (number of sampled time points, 12 for a 5–6 minute video) and install (in-place engine download vs. reporting the install location). start/end are implied by 'only download this segment' and url is self-evident, but width is never explained.

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: read text on screen via local offline OCR, explicitly noting it does not use audio or platform subtitles. This clearly separates it from siblings like video_subs (subtitles) and video_visual_scan (general visual scanning).

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 trigger condition — use it after video_brief reports 'almost no speech, text all on the picture' — and names the alternative scenario it is not for. The routing logic is directly actionable.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that it performs no download and that segmentation is based on cut points and long silences, and it describes the recommended follow-up workflow. However, it does not state output structure, latency, cost, or any permission/authentication requirements.

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 no filler. The core purpose and the workflow recommendation are front-loaded and easy to scan.

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?

The description covers the tool's purpose and workflow role, which is the most important context. But for a tool with no annotations, no output schema, and 0% schema description coverage, it leaves the window parameter and the shape of the returned chapters/order unexplained.

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%, and the description does not mention either parameter. The url is obvious from context, but the window parameter and its default of 300 are completely unexplained, so the description fails to compensate for the schema gap.

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 states a concrete verb and resource: split the video into chapters at cut points or long silences and recommend a viewing order. It also explicitly distinguishes this tool's role from sibling tools by directing the agent to call it first for long videos before using video_window or video_sheet.

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?

It gives explicit when-to-use guidance (long videos, call this first) and when-not-to-do-something (do not transcribe the entire film immediately). It names the alternative tools to use afterward and how many chapters to pick, leaving little to inference.

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

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

With no annotations at all, the description does carry some real burden: it discloses the cost profile (only the segment is fetched, 20s ≈ 0.9MB), the single-image output form, and that timecodes are burned in. It omits what happens on fetch failure, how the grid dimensions affect output size, and whether the returned image is inline content or a file reference.

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, front-loaded with the distinguishing behavior and a concrete size example that earns its place by conveying cost. The quoted colloquial use-case phrase is slightly informal but functional; nothing is padded.

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?

Because there is no output schema, the description's explanation of the returned contact sheet is genuinely needed and delivered. However, for a tool with six parameters, zero schema coverage, and zero annotations, the absence of any parameter-level guidance leaves the agent guessing on grid layout and resolution.

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?

Six parameters with 0% schema description coverage and no annotations, and the description only indirectly gestures at start/end via '这一段' and the '20 秒' example that matches the end default. cols, rows, height, and the url parameter are entirely unexplained, so the text fails to compensate for the schema gap.

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 states a concrete output artifact (a tiled contact sheet with absolute timecodes burned into each cell's top-left corner) plus a scope constraint (only this segment is downloaded). This is far more specific than the bare name 'video_sheet', though it never names or contrasts the closest siblings such as video_frames or video_visual_scan.

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 implied use case — quick orientation/overview of a clip — which is real guidance. But there is no explicit when-not condition, no mention of when to prefer video_frames / video_window / video_visual_scan, and no prerequisites (e.g. does the url need to be directly downloadable?).

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

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

With no annotations, the description carries the burden and does so well: it discloses download cost (~60s ≈ 1MB), clarifies probabilities are model outputs rather than facts, and instructs cross-checking against the visual. These are exactly the behavioral traits an agent needs and none are in structured fields.

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?

Dense and front-loaded: purpose, coverage, limitation, cost, and caveat each appear as a distinct clause with little waste. Slightly list-like but every sentence earns its place.

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?

Strong on behavioral and semantic context (what it detects, cost, output nature, caveats) but weak on the mechanics of its 7 undocumented parameters and no output schema is present. An agent knows what the tool is for but not precisely how to tune its 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 coverage is 0% across 7 parameters, and the description explains none of them — start/end, hop, window, top_k, min_prob are all left to the schema titles and defaults. The only implicit hint is the 60-second segment size. For a 7-param tool this leaves the agent guessing how to configure sensitivity and windowing.

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 — sound-event multi-labeling over an audio segment — and explicitly distinguishes it from transcription ('what was said'). The AudioSet 527-class / probability / timecode output description makes the operation unambiguous and separable from speech-oriented siblings like video_subs.

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?

Clearly frames the when-to-use ('not what was said') and gives concrete coverage examples (chewing, knocking, water) plus an explicit limitation (drinking/swallowing has no class). It doesn't name a specific alternative sibling for the speech case, 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.

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 key traits: read-only, no media download, and a fallback-priority order for subtitle sources. It does not cover permissions, rate limits, or the shape of the returned data, which keeps it from a 5.

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 dense sentences: capability and constraint first, then the routing advice. Every clause carries information and nothing is redundant.

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 tool with no annotations and no output schema, the description explains purpose and routing well, but leaves the parameters undocumented and says nothing about what the returned subtitle data looks like (format, timestamps, truncation by limit). Adequate but with clear gaps.

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% and none of the three parameters (url, lang with default 'zh', limit with default 200) are explained in the description. The 'lang' default is especially consequential given the dialect discussion, but no guidance is given on overriding it or on what 'limit' bounds.

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 gives a specific verb and resource — reading platform subtitle tracks — and states the selection preference (manual subtitles first, auto subtitles second) plus the '0 media download' constraint. This clearly separates it from video_audio (ASR) and video_frames/video_visual_scan (hard-coded subtitles).

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?

It explicitly says when to use it (heavy dialect/accent, uncertain ASR) and what to do if it fails ('if none, then use ASR or check hard-coded subtitles in the frames'), naming both alternates. There is no ambiguity about routing.

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

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

With no annotations, the description carries the full burden and does well: it discloses that a lowest-quality video is downloaded (approx. 14-21MB for 7 minutes) and deleted afterwards, so the agent knows about cost and cleanup. It omits failure behavior (bad URL, inaccessible video) and does not describe the returned image's layout beyond "stitched."

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 tightly packed sentences: what it does first, then when to use it, then the cost caveat. No filler, and the critical constraint is front-loaded.

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?

No output schema and no annotations, so the description must cover purpose, cost, and usage, which it does. What's missing is the meaning of cols/rows and any note on how the resulting image is laid out, which matters for interpreting the returned contact sheet.

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. It explains n (number of frames) and the sampling rule, but cols and rows (the grid layout of the stitched image, defaults 6x4) are never mentioned anywhere, and url is only implied. Half the parameters remain opaque.

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: uniformly sample n frames across the video, burn absolute timecodes, stitch into an image and return it. It also indicates cut-point-aware sampling, which no sibling exposes. It does not distinguish itself from close siblings like video_frames or video_sheet, which also deal with visual frames, so a perfect score is not warranted.

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?

"Used for videos without sound, or long stretches without speech" gives a clear selection condition and implicitly steers audio-capable tasks to video_audio / video_soundscape / video_subs. However, it never names an alternative tool or states an explicit exclusion, so the agent must infer the routing.

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

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

With no annotations, the description carries the load well: it discloses statefulness (progress is persisted and can be cleared via cursor="stop"), the default chunk size, and that returns include point summaries plus a seen/total percentage and an explicit completion signal. It does not explain what the 'session' parameter does for progress isolation, which is a notable gap for a stateful tool.

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 one-line summary followed by bulleted call patterns, so the important scoping and sequencing information is easy to scan. Slightly padded by the near-duplicate framing sentence ('一段一段看、看一点说一点'), but no bullet is wasted.

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 6-parameter stateful tool with no annotations and no output schema, the description covers call sequencing, mutation of stored progress, chunk sizing, and the shape of the return (progress percentage, completion notice). Remaining gaps are the session parameter and the lang/model knobs, which an agent may need to use correctly.

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 documents cursor's semantics (next/restart/stop) thoroughly and implies minutes via the '5 分钟' default, but leaves url, lang, model, and especially session unexplained.

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 action and resource: incremental, segmented viewing of a video that advances one chunk at a time (default 5 min, ~1k chars) and then stops for the caller to decide. It explicitly names the siblings it is not: video_window for verbatim text and video_brief(level="full") for a full pull.

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 call sequence — first call starts at 0, subsequent calls pass cursor="next", cursor="restart" rewinds, cursor="stop" clears progress — plus a clear exclusion ('do not use video_brief(level="full")') and a redirect to video_window. The when-to-use-vs-alternative mapping is fully spelled out.

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

Does 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.

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

No annotations are provided, so the description carries the full burden. It discloses the scope of checks and that failures are reported explicitly (哪里断了直接说), but never states that it is read-only and safe, whether it makes network calls with side effects, or how long a full probe takes. Adequate but shallow for a zero-annotation tool.

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, front-loaded with the verb and the checklist. The telegraphic style is efficient, though the slash-separated list is slightly terse enough to read as a note rather than guidance.

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 zero-parameter diagnostic with no output schema, listing the checked subsystems and stating that breakage is reported directly is nearly enough. Missing only whether repeated invocation is harmless and roughly what the report contains.

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 tool takes zero parameters, so baseline is 4. Nothing about parameters needs explaining, and the description correctly spends no words on them.

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 action (self-check / 自检) and enumerates exactly what is inspected: python, ffmpeg, yt-dlp, dependencies, whisper model, disk, network. This is clearly distinct from the video_* siblings. It doesn't explicitly distinguish itself from vidlens_models, which also touches the whisper model area.

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 implication that you run this when something is broken is present but only implied, and there is no explicit when-to-use / when-not-to-use or mention of vidlens_models as an alternative. An agent can reasonably infer this is the first-call diagnostic, but it is not stated.

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

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

With zero annotations, the description carries the full burden and does the most important job: it discloses the two-phase download safety gate — without confirm=true the call only reports size and install location, and only confirm=true actually fetches. Undisclosed traits remain (default install path, disk-space/overwrite behavior, whether the download blocks or is async, network failure handling), which keeps this below 5.

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?

Purpose and the size/location/confirm guarantees come first, followed by a compact per-action breakdown — well front-loaded with no filler. The slash-delimited, bolded telegraphic style is slightly dense to parse but every clause carries information an agent needs.

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?

Three optional params, no annotations and no output schema mean the description must stand alone. It covers the risky path (download) but says nothing about what list/recommend return, whether download is long-running, or what happens on a partial/failed install — gaps that matter for a tool that mutates local disk.

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. It effectively documents `action` (three named values with meanings) and `confirm` (gates the real download), but `name` — the parameter that selects which model — is only implied by "装某个模型" with no format or accepted values. The parenthetical about "换目录" (changing directory) also hints at configuration that no parameter exposes, leaving a gap.

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 names the resource (local model catalog / hardware recommendation / download) and enumerates three concrete verbs via action=list, action=recommend, action=download, each with its own scope. An agent can tell immediately that this tool manages models rather than video content, distinguishing it from the video_* siblings without opening the schema.

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?

Each action value is given a use condition: list to see the catalog with resolved local paths, recommend to pick a model for this machine, download to install one. However, there is no guidance on ordering (e.g. call recommend before download), no exclusion of when-not-to-use, and no mention of the vidlens_doctor sibling for environment problems.

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