解析短视频/图文分享链接，返回无水印直链。
支持平台：抖音、快手、小红书、哔哩哔哩、微信视频号、微博、知乎等。
参数 url 可以是分享文本（含口令的整段文字）、短链（如 https://v.douyin.com/xxx/）
或完整链接。返回字段见下：视频类看 video_url / qualities，图集类看 images，
背景音乐看 music_url。所有直链均为平台 CDN 地址，请自行下载（有时效，过期重解析）。
Args:
url: 分享文本、短链或完整视频/图文链接。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it discloses that links are unwatermarked, resolve to platform CDN addresses the caller must fetch itself, and are time-limited so an expired link requires re-parsing. It does not mention authentication requirements, rate limits, or what happens for unsupported/private content, which keeps it short of 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?
Front-loaded: the core action and return type appear in the opening line, followed by platform coverage, input forms, and output field hints in that order. The trailing Args block largely restates the url sentence already given above, which is the only wasted text.
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 one-parameter extraction tool with an output schema present, the description covers platform scope, all three input forms, which return fields matter for video vs. image-set vs. music, and the download/expiry caveat. Failure modes such as unsupported platforms or private/deleted content are not addressed, which is the remaining gap.
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 single url parameter has no schema description, so the description must compensate — and it does, explaining that url may be raw share text, a short link, or a complete link, with a concrete example format. It adds real meaning over the bare {"type": "string"} schema, though it stops short of stating tolerance for extra whitespace or invalid input.
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 first line names a specific verb and resource (解析分享链接) plus the concrete outcome (返回无水印直链), and the platform list immediately frames the scope. Against siblings get_balance and redeem_code there is no ambiguity whatsoever.
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 spells out the accepted input shapes — share text containing a token, a short link like https://v.douyin.com/xxx/, or a full URL — which is exactly the decision an agent faces before calling. It also tells the caller what to do afterwards (download the CDN link yourself, re-parse if it expires). No explicit when-not-to-use case or alternative tool is given, but the siblings are unrelated, so nothing is really missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.