Fetch read-only platform subtitle tracks, preferring human captions over auto-generated ones, without media download. Check original subtitles when accents or ASR confidence hinder transcription.
只读平台字幕轨（人工字幕优先，其次自动字幕），0 媒体下载。 方言/口音重、ASR 不确定时，先看这里有没有原字幕；没有再用 ASR 或看画面硬字幕。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| lang | No | zh | |
| limit | No |
Changes observed during successful MCP inspections.
v1.6.3Does 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.