Skip to main content
Glama

Overview

media_overview
Read-only

Generate a readable overview of a local video, audio file, or document: storyboard grids with time-aligned text, timestamped transcripts, or page thumbnails with extracted text.

Instructions

Build an overview of a local media file so you can read it without guessing. (生成媒体总览:视频出分镜宫格图与按时间对齐的文本清单;录音出带时间轴的转写;文档出页面缩略图与每页文字。)

What you get depends on the media:

  • video : one or more numbered storyboard grids (each cell carries its cell number) plus a time-aligned text index of every cell

  • audio : a timestamped transcript, segment by segment

  • document : a grid of page thumbnails plus the text of each page, when a document parser is configured

TEXT SOURCE ORDER — subtitles first, ASR only as a fallback:

  1. a transcriptFile you pass in (external subtitle file),

  2. the subtitle track embedded in the container,

  3. a subtitle file with the same base name in the same directory (a.srt next to a.mp4),

  4. ASR — only when none of the above exists and an ASR provider is configured. Every segment is tagged with its source. subtitle = the author's own words, safe to quote. asr = machine transcription: names, numbers and jargon are often wrong, so do NOT quote an ASR segment verbatim and do not present it as the speaker's exact words. visual = there is no text at all, only the picture.

The storyboard grid is for FINDING things, not for reading them: cells are small, so text inside a cell is usually unreadable. To read text on screen, call media_zoom on that moment and read the cropped single frame.

The full text is NOT inlined. It is written to disk and the returned paths point at it: content.md (readable), segments.jsonl (one segment per line, machine-readable), manifest.json (what was produced and how). Read those files section by section and summarise them in chunks yourself — do not ask for the same range again just to get more inline text.

Always call media_probe first: it tells you how long the file is, whether a subtitle source exists, and which transcript source applies, for free. Long media must be narrowed with start/end (video, audio) or pages (document) — one giant grid of a two-hour film gives you illegible cells and spoils the ending. Follow the continuation hint in the result to page through the rest.

Input Schema

NameRequiredDescriptionDefault
endNoWindow end in seconds (closed interval, both ends included). Applicable to video and audio only. Defaults to the end of the media; a value past the end is clipped and reported. (终点,秒)
pathYesAbsolute path to a LOCAL file: video, audio recording, or document. URLs and relative paths are rejected — this server never downloads anything. (本地文件绝对路径)
cellsNoCells per puzzle image: storyboard shots for video, page thumbnails for document. 1-16; default 9 for video and 6 for document. Applicable to video and document only. (每张拼图的格数)
pagesNoPage range for document media: comma-separated 1-based page numbers and closed ranges, e.g. "3-10,15". Not applicable to video or audio. (页码范围)
startNoWindow start in seconds (closed interval, both ends included). Applicable to video and audio only; document media uses "pages" instead. Default 0. (起点,秒)
imagesNoHow many puzzle images to return: 1-4, default 2. Applicable to video and document only. (返回几张拼图)
maxEdgeNoLongest edge of each image in pixels: 256-1600. Default 1280 for overview, 1600 for zoom. Applicable to video and document only. (单张图最长边)
segmentNoWindow length in seconds (30-3600, default 300), used when only "start" is given. Applicable to video and audio only.
envelopeNoAttach an audio envelope waveform image (default false). Applicable to audio recordings only. (音频包络图)
transcriptNo"auto" (default): use subtitles first, ASR only as a fallback. "off": no transcription at all, visuals only. Applicable to video and audio only.
transcriptFileNoAbsolute path to a local subtitle/transcript file (.srt, .vtt, .ass, .ssa). Applicable to video and audio only. (本地字幕/转写文件)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and closed-world, and the description is fully consistent while adding substantial behavior: a four-step text-source precedence order, per-segment source tags, a strong warning not to quote ASR verbatim, and the fact that full text is written to disk (content.md, segments.jsonl, manifest.json) rather than inlined. It also discloses the key failure mode — storyboard cells are too small to read — that annotations cannot express.

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

Conciseness4/5

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

Structure is strong — scoping sentence, per-media output list, source-precedence block, then caveats and return-value paths — and the most important warnings are front-loaded or visually separated. It is nonetheless verbose (bilingual restatement plus some overlap between the output list and the file-path paragraph) where a tighter version would lose nothing.

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

Completeness5/5

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

Eleven parameters with no output schema make this a complex tool, and the description covers what an agent needs: what is produced per media type, that text lives at returned disk paths and should be read section by section, how to page through long media, and the quoting caveat for ASR. Nothing material is left for the agent to guess.

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 schema already carries parameter mechanics and the baseline would be 3. The description still adds motive that guides parameter choice: why windows must be used (illegible cells, spoilers), that start/end are video/audio-only while documents use pages, and the subtitle-vs-ASR consequence of transcript="auto" vs "off" via the source order. It stops short of adding format specifics beyond what the schema states.

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

Purpose5/5

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

Opening sentence names a specific verb and resource ("build an overview of a local media file") and immediately enumerates the three media types with the exact artifact produced for each. It also disambiguates the outputs from the sibling tools by naming media_zoom for reading text and media_probe for probing, so an agent can place this tool in the workflow without opening a schema.

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

Usage Guidelines5/5

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

Explicit sequencing and exclusions: "Always call media_probe first", "To read text on screen, call media_zoom on that moment", and long media "must be narrowed with start/end or pages". It also tells the agent to follow the continuation hint rather than re-requesting the same range, which is precisely the kind of when/when-not guidance that prevents bad calls.

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