Skip to main content
Glama

video_review

Plan, acknowledge, and finish host-chosen visual evidence scopes with bounded image receipts, enabling agents to track inspected frames and resume pending batches after failures.

Instructions

Manage the HOST-CHOSEN evidence scope and bounded image receipts. action=status returns the plan, acknowledged indices, pending batch and nextAction. plan: visual=all means all generated images for this task; selected requires indices; none permits text-only evidence. Text processing status, coverage and pagination remain available through transcript_read, but text reading is not tracked or enforced by this review. There is no fixed global completeness or ASR requirement. ack: after actually inspecting a returned batch, explicitly supply batchId and viewedIndices; [] releases the batch without claiming inspection. Unchosen images may be skipped. replay returns the same pending batch after transport failure. reviewId resumes this consumer ledger after server restart; omitting it creates a fresh consumer when not already active. finish checks only the selected plan; it returns finished=false with missing work instead of inventing completeness. The Agent must assess adequacy to the user, keep its own semantic notes, and distinguish actual source coverage from acknowledged images. No descriptions or summaries are generated here.

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_review"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
actionNo
visualNo
batchIdNo
indicesNo
reviewIdNo
viewedIndicesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / textTrackIds
      Removed value: -{
      -  "items": {
      -    "format": "uuid",
      -    "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
      -    "type": "string"
      -  },
      -  "maxItems": 8,
      -  "type": "array"
      -}
  2. First observedv0.9.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false, idempotentHint=false, destructiveHint=false and openWorldHint=false; the description goes well beyond that by disclosing that ack is a caller assertion rather than proof of comprehension, that [] releases a batch without credit, that replay re-serves the same pending batch, that reviewId resumes a ledger after server restart, and that finish returns finished=false with missing work. It does not explain the non-idempotent/non-readonly semantics of plan and ack against the annotations, which is the remaining gap.

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 runs roughly 500 words with heavy repetition: the independence of subtitles/ASR/images is restated three times, and the pending-batch/ack workflow is described twice in different words. It also drifts into agent policy rhetoric ('Honest incomplete-work disclaimers do not justify abandoning feasible work', 'user_cancelled is only for an explicit user cancellation') that is not tool-definition content. Front-loading is weak because the actionable per-action semantics compete with normative commentary.

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 describe returns (status yields plan, acknowledged indices, pending batch, nextAction; finish yields finished=false with missing work), and it covers the resume and retry paths. However it leaves the required `id` argument undefined and never states failure/error behavior for a bad batchId or an invalid viewedIndices entry. Content is plentiful but disorganized enough that an agent may still need to experiment.

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 description coverage is 0%, so the description must carry the burden, and it largely does: it defines the action values, the visual enum (all = all generated images, selected = requires indices, none = text-only), batchId and viewedIndices for ack, reviewId for resume, and the [] release convention. The required `id` parameter is never mentioned at all, which is a real omission for the one mandatory argument.

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: manage the HOST-CHOSEN evidence scope and bounded image receipts, then enumerates all five action values (status/plan/ack/replay/finish) and what each returns. It also separates itself from siblings by naming transcript_read, video_read, audio_start/audio_url_start and stating what is and is not tracked by this review. The purpose is discernible but buried in dense policy prose, so it falls short of a clean 5.

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

Usage Guidelines4/5

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

There is abundant when-to-use guidance: use plan to record visual=none|selected|all and revise as evidence changes, ack only after actually inspecting a batch with explicit viewedIndices, replay after transport failure, finish before finishing, and use audio_start for text-only media without a visual job. Alternatives and exclusions are named (transcript_read for text, session_stop for cleanup, user_cancelled only for explicit cancellation). It loses a point because the guidance is scattered and repetitive rather than a crisp ordered workflow.

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