Distributed Video QA MCP

Download a video or its audio

video_download

Download a public video link to a playable file by fetching video and audio streams and muxing them, with selectable quality, container, audio format, and output folder.

Instructions

Save a link to a file. Fetches video and audio streams in parallel fragments and muxes them into one playable file, preferring H.264/AAC for MP4 so it opens everywhere. Returns a Job whose result is a DownloadReport.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "video_download"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes	Public http(s) link to a single video.
`mode`	No	'video+audio' merges the best audio track into the chosen video quality.	video+audio
`quality`	No	'best' or a maximum height such as '1080p' or '720p'.	best
`container`	No	Video file type.	mp4
`format_id`	No	Exact id from video_probe, e.g. '136' or '136+140'. Overrides quality.
`output_dir`	No	Folder to write into (under DVQA_ALLOWED_ROOTS).
`audio_format`	No	File type for audio_only.	m4a
`wait_seconds`	No	Seconds to wait for completion before returning the job.

Output Schema

Name	Required	Description
`kind`	Yes	What the job does.
`next`	No	The call to make to keep waiting, while the job is unfinished.
`error`	No	'code: message — hint' when the job failed.
`stage`	Yes	Current step: queued, download, transcribe, frames, embed or done.
`job_id`	Yes	Pass to video_job to poll, or video_cancel to stop.
`result`	No	When succeeded: the ingest report (video_id, counts, stages, embedding tokens, elapsed seconds) or the download report (path, codecs, size, whether audio was merged).
`source`	Yes	The URL or path being processed.
`status`	Yes	`interrupted` means the server restarted mid-job; ingest again to resume.
`message`	Yes	Latest human-readable progress line.
`progress`	Yes	Overall completion from 0 to 1, weighted by how long each stage usually takes.
`video_id`	No	Known once the source has been resolved; use it with every other tool.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Nov 13, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations only declare mutation, open-world, and non-destructive; the description adds real behavior beyond that: parallel fragment fetching, muxing into one file, codec preference for MP4 compatibility, and asynchronous Job-based completion. It does not spell out where files land or the write implications of a non-read-only tool, which the schema only partially covers via output_dir.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the core action and then proceeding to mechanism and return type. No filler. The opening phrase is the only weak spot and costs it a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description still names the Job/DownloadReport contract. For an async, multi-parameter download tool with 100% schema coverage, everything an agent needs to call it correctly is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are fully documented in structured data and the baseline is 3. The description adds only indirect meaning, linking the H.264/AAC preference to the container choice; it says nothing about mode, quality, or wait_seconds beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete action and resource: it fetches video/audio streams and writes them to a playable file, and it explicitly returns a Job with a DownloadReport. 'Save a link to a file' is slightly loose phrasing (it could read as bookmarking), but the following sentences remove that ambiguity. It does not explicitly contrast itself with siblings like video_probe or video_clip, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the tool is for getting media onto disk, and the mention of format_id 'from video_probe' in the schema hints at a probe-then-download flow. The description never states when to prefer this over alternatives, nor any exclusions such as playlists versus single videos. Adequate but with clear gaps.

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