Extract video from a page URL and produce a universal MP4 file and a separate MP3 audio file.
Downloads a video from url extracted from the page and generates both a universal MP4 (H.264/AAC/FastStart) and a separate MP3 audio file.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the page of the video to download |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It does so by disclosing that two outputs are generated, including the MP4 codecs (H.264/AAC) and FastStart flag. It does not mention return values, save location, or failure conditions, but the main side effect is clearly described.
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 a single sentence with no filler. Key information is front-loaded (downloads a video) and the output formats/codecs are added efficiently.
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 tool has only one required parameter, no enums, and no nested objects, so complexity is low. The description is sufficient for an agent to know what to pass and what outputs to expect, though details about return values or download location would make it more complete.
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 schema already documents the single url parameter with 100% coverage. The description adds a slight nuance by referring to a URL 'extracted from the page,' but this mostly restates the schema's existing 'URL of the page' wording.
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 action ('Downloads') and a specific resource (video from a page URL), then names the exact output artifacts: universal MP4 and separate MP3. This clearly distinguishes it from extract_video_info, which is about inspecting video metadata rather than downloading media.
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 intended use case is obvious: call this tool when a video should be downloaded and converted to MP4/MP3. It does not explicitly name alternatives or exclusions, but the sibling tool names make the decision reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.