video-sense

Overview Schema Source Related Servers Discussions Admin

transcript_start

Starts an independent ASR or subtitle text track for a ready audio/video job and returns a track ID for cursor-based transcript reads.

Instructions

Start an independent text track for an existing ready audio task or file/URL video job. mode=asr (default) uses the configured optional backend; no cloud fallback, opening a source does not load a model. mode=subtitles without trackId lists network tracks (selection_required when nonempty, no_tracks when empty); call again with an exact listed trackId to fetch. Separate local subtitle/transcript files stay with the Agent; this server does not import them or extract embedded local subtitle streams. Use optional ASR for local audio. start/end default to opened source range; explicit ranges must be valid source seconds, max1800s per task. Audio acquisition drains independently into a 64MiB bounded WAV spool; first-block ASR starts before acquisition ends. Network acquisition prefers streaming, with bounded HTTP reconnects and one source-position retry. audioFallback=on_failure (default) downloads the complete same resolved audio ONLY after both source-stream attempts fail; never disables that fallback. Downloads are limited to 1GiB/network task and 30min, retain partial files, and store only audio when the source is muxed. Cancellation, rejected sources, local/disk errors and ASR backend failures do not trigger downloads. audioTransfer records mode/reason/resume position and downloaded file; source timing and processed coverage remain explicit. Selected page entry/source is inherited from the media task, never title-matched. Returns a text track ID immediately; use transcript_read and its nextAfter cursor. force bypasses completed cache. session_stop cancels source/text, retains evidence.

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": "transcript_start"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes
`end`	No
`mode`	No
`force`	No
`start`	No
`backend`	No
`trackId`	No
`language`	No
`audioFallback`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.9.0Nov 5, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Annotations only state readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds substantial behavioral context beyond that: no cloud fallback, 1GiB/30min download limits, partial file retention, fallback only after both source-stream attempts fail, force bypasses completed cache, and a text track ID is returned immediately. Some of this material belongs to other tools, but the tool-specific behavior is unusually well disclosed.

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 very long and sprawling, with large sections about image batches, video_review acknowledgement, session_stop, and other workflows that do not help an agent invoke transcript_start. Key call parameters are buried mid-paragraph instead of front-loaded. The opening sentence is good, but the overall structure is diluted by extensive off-tool material.

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?

For a 9-parameter tool with no output schema, the description covers the main return value, mode behavior, range constraints, fallback and download behavior, cancellation semantics, and cache bypass. It still omits meaning for id and language and adds substantial irrelevant workflow detail. The description is lengthy but not structured around what an agent needs to call this specific tool correctly.

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 0%, so the description has to carry parameter meaning for all 9 parameters. It explains mode, trackId, start/end defaults and limits, force, and audioFallback reasonably well, and touches on backend. It leaves id and language unexplained and only vaguely defines backend, so it partially compensates for the coverage gap but does not fully cover 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 first sentence states a specific verb and resource: start an independent text track for an existing ready audio task or file/URL video job. It also distinguishes the two modes, asr versus subtitles, and mentions transcript_read as the read-side companion. The purpose is clear, but it is embedded in a long block of workflow text, so the boundary from siblings is less front-loaded than it could be.

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?

The description gives real mode guidance: mode=asr is the default using the configured optional backend, and mode=subtitles without trackId lists network tracks and requires a second call with an exact listed trackId. However, much of the remaining text routes the host through video_review, image batches, and other tools rather than explaining when to call transcript_start versus transcript_read or the audio_start tools. Usage guidance for this tool is present but mixed with extensive unrelated workflow guidance.

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

Deploy Server