video-sense

Overview Schema Source Related Servers Discussions Admin

video_status

Read-only

Check video processing and delivery status, optionally waiting up to 20 seconds for a terminal state or deadline, to see whether production finished and which images were delivered or missing.

Instructions

Get local/network state. waitSeconds (0..20) waits until terminal state or deadline. Use video_read/video_next for incremental actual images. complete means production finished, NOT images consumed. visualDelivery separately reports generated/delivered counts, missing index ranges and allDelivered. overview is only sampled windows, see coverage. videoTransfer reports stream attempts and complete-video download/local decode fallback when used.

The HOST chooses evidence depth from the user request and actual subtitle/ASR quality and coverage: text alone, selected storyboards, all storyboards, or targeted higher-quality follow-up. Subtitles, ASR and images are independently optional; choose any combination. For text-only media use audio_start/audio_url_start (audio-bearing video files/pages are accepted) without a visual job. No mandatory image retrieval, all-images rule, fixed answer format or mandatory ASR. Use video_review action=plan to record visual=none|selected|all; revise as evidence changes. Missing subtitles do NOT block usable images, and a video-only stream does not prove missing source audio. Each image response has a pending batch. Return images AND timestamp metadata to the model, inspect the chosen images, then call video_review action=ack with batchId and explicit viewedIndices (empty [] releases uninspected images without credit). ONLY THEN fetch another batch. Never accumulate many video_read calls inside one code/exec result: return control to the model after each bounded batch. Transport errors leave the batch pending: video_review replay retries it; status/reviewId support resume. Acknowledgement is a caller assertion, not proof of comprehension. Keep any semantic working notes in the Agent workspace, not in MCP evidence. Before finishing, video_review finish checks only the HOST-CHOSEN visual scope and pending image receipts, not text reading completion. The host must still judge if that scope answers the user, and state relevant gaps. Honest incomplete-work disclaimers do not justify abandoning feasible work. session_stop cleanup cancels processing but does not complete reading; user_cancelled is only for an explicit user cancellation. Audio-only workflows remain independent.

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": {
      "id": "<id>"
    },
    "name": "video_status"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes
`waitSeconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.9.0Nov 5, 2026

TDQS

B3.3/5.0

Behavior4/5

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

Beyond the readOnly/idempotent annotations, the description discloses real behavior: waitSeconds blocks until a terminal state or deadline, 'complete' means production finished rather than images consumed, visualDelivery reports generated/delivered counts and missing ranges, overview is sampled windows, and videoTransfer reports fallback download/decode. That is substantive context an agent could not get from the annotations.

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

Conciseness2/5

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

The description is a long, dense block that mixes return-value semantics with extensive host-policy instructions about evidence depth, acknowledgement discipline, and session cleanup. Much of it does not describe this tool at all, and the useful status semantics are buried mid-paragraph rather than front-loaded.

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

Completeness3/5

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

With no output schema, the description does need to explain return fields, and it covers complete, visualDelivery, overview and videoTransfer reasonably. But it omits the shape of the response overall and spends most of its length on workflow rules, leaving the status contract only partially specified.

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 0%, so the description must carry parameter meaning, and it does explain waitSeconds as a 0..20 second wait until terminal state or deadline. The required 'id' parameter is left unexplained, but its meaning is obvious from context, so the gap is minor.

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

Purpose3/5

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

The opening 'Get local/network state' is vague about what state is being retrieved; only the tool name and later mentions of 'complete', 'visualDelivery' and 'overview' imply this is a video job status endpoint. It never states plainly that it returns processing/transfer status for a video job, so an agent must infer the resource from the name rather than the description.

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?

It does route the agent away from this tool for image retrieval ('Use video_read/video_next for incremental actual images'), which is useful. However, it gives no explicit guidance on when to call status versus siblings like audio_status, video_evidence or video_review, and the bulk of the text is host workflow policy rather than tool-selection guidance.

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

Deploy Server