Distributed Video QA MCP

Index several videos or a playlist

video_ingest_batch

Start ingest jobs for multiple video sources, expand playlists and channels, queue excess jobs, and report bad sources without stopping the batch.

Instructions

Start one ingest job per source. Playlist and channel URLs expand to their first playlist_limit videos. Jobs run DVQA_MAX_CONCURRENT_JOBS at a time and the rest queue; a bad source is reported in skipped without stopping the others.

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": {
      "sources": "<sources>"
    },
    "name": "video_ingest_batch"
  }
}

Input Schema

Name	Required	Description
`frames`	No	Sample and embed frames.
`quality`	No	Download height for URLs.
`sources`	Yes	URLs or local paths; playlists expand.
`language`	No	Spoken language code. Omit to detect.
`transcribe`	No	Transcribe the speech.
`wait_seconds`	No	Seconds to wait for completion before returning the job.
`playlist_limit`	No	Videos taken from each playlist.

Output Schema

Name	Required	Description
`jobs`	Yes	One per video, in source order after playlist expansion and de-duplication.
`skipped`	No	Sources that were not started, as 'source: code: reason'.
`expanded`	No	Playlists that were expanded, as 'url -> N videos'.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Nov 13, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing concurrency limits (DVQA_MAX_CONCURRENT_JOBS), queueing of excess jobs, playlist expansion behavior, and partial-failure semantics where bad sources land in `skipped` without aborting the batch. It still doesn't state that the call returns immediately with job handles rather than finished videos, or how wait_seconds changes that.

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

Conciseness5/5

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

Three short sentences, front-loaded with the core action, then expansion semantics, then concurrency and failure handling. Every sentence carries information not present elsewhere; there is no filler.

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

Completeness4/5

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

For a 7-parameter, open-world batch mutation with an output schema, the description covers the non-obvious behavior (concurrency, queueing, partial failure, expansion). The main remaining gap is the async/return contract around wait_seconds, which the output schema partly compensates for.

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

Parameters4/5

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

Schema coverage is 100% so the baseline is 3, but the description adds real meaning: it clarifies that `playlist_limit` governs expansion per source and that channel URLs (not mentioned in the schema) also expand. It says nothing about frames/transcribe/quality/language, which is acceptable given the schema documents them.

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 opens with a specific verb+resource ('Start one ingest job per source') and makes the batch/multi-source scope explicit, which separates it from a single-source ingest conceptually. It never names the single-item sibling, so differentiation is implied rather than stated.

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 by 'one ingest job per source' and the playlist/channel expansion note; an agent can infer this is for multiple sources or a playlist. No explicit when-to-use / when-not-to-use guidance or redirect to video_ingest for a single URL is provided.

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