Distributed Video QA MCP

Gather evidence for a question

video_ask

Read-only

Answers questions from indexed videos by returning timestamped transcript moments and frames as evidence; optionally verifies whether the video supports the answer.

Instructions

The moments most relevant to a question, as evidence: for each, the transcript around it with timestamps and the frames from it as images (in moments order). Answer from the evidence and cite times. With verify, each moment carries calibrated support probabilities and evidence.supported says whether the video answers the question at all.

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": {
      "question": "<question>"
    },
    "name": "video_ask"
  }
}

Input Schema

Name	Required	Description
`verify`	No	Have Jev 1.14 judge whether each moment's transcript answers the question and whether each frame shows it, rerank by that, and rescue with a frames-only search when nothing is supported. Sends excerpts and frames to TypeSafe. Default: DVQA_VERIFY (off).
`image_px`	No	Long side of returned images, in pixels.
`question`	Yes	The question to answer from the video(s).
`video_ids`	No	Limit to these video ids. Omit for every indexed video.
`max_moments`	No	Moments to return.
`frames_per_moment`	No	Images attached per moment.

Output Schema

Name	Required	Description
`moments`	Yes	Most relevant first.
`evidence`	Yes	How strongly anything matched.
`guidance`	Yes	How to use the evidence.
`question`	Yes	The question asked.

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 already declare readOnlyHint=true and openWorldHint=false, and the description adds real behavioral context beyond them: results are ordered in `moments` sequence, each moment bundles a timestamped transcript window plus image frames, and with verify the moments carry calibrated support probabilities and an `evidence.supported` verdict that can indicate the video does not answer the question at all. It does not mention return volume limits or that verify sends data externally (that detail lives in the schema), so it is strong but not exhaustive.

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 dense sentences with no filler; the evidence bundle is described first, then the answering instruction, then the optional verify mode. Every clause carries information, though leading with the return payload rather than the action is a minor structural quirk.

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?

An output schema and full parameter descriptions already carry return structure and limits, and rich annotations cover the safety profile, so the description only needs to convey intent and the verify mode, which it does. A brief note on default video scope or result caps would close the remaining gap, but nothing essential is missing for correct invocation.

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?

With schema description coverage at 100%, every parameter including verify, image_px, max_moments, and frames_per_moment is already documented in the schema. The description adds a little meaning by tying `verify` to support probabilities and `evidence.supported`, but adds no syntax or defaulting detail beyond what the schema supplies, so the baseline 3 applies.

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 frames the tool as returning 'the moments most relevant to a question, as evidence' with transcript windows and frames, which makes the retrieval-and-answer purpose legible even though the operative verb is implicit and the tool is never named against siblings like video_transcript or video_search. The output-shape framing implicitly distinguishes it from a raw transcript dump, but an agent must infer the differentiation rather than being told it.

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?

'Answer from the evidence and cite times' gives downstream usage guidance, and the 'With verify' clause flags a conditional mode, but there is no explicit when-to-use-this-vs-alternative statement (e.g. when to prefer video_transcript or video_search_by_image). Usage is implied by the return shape rather than instructed.

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