ReelVision lets Claude, ChatGPT and other MCP clients watch short-form videos. Paste a reel link and the model gets the caption, a timestamped transcript and up to 20 keyframes, so it can explain, summarize or recreate what’s in the video. It can zoom into any timestamp to read small on-screen text or catch fast cuts.
Works with Instagram, TikTok, Facebook and X. Built for designers and developers who save reels for inspiration and want AI to turn them into real work.
Scored across 3 tools
The three tools are largely distinct: reel_transcript is explicitly text-only, watch_reel adds visuals, and zoom_frames is for targeted high-resolution grabs. The only soft overlap is that watch_reel already returns keyframes, so an agent might wonder when zoom_frames is warranted, but the descriptions resolve this with clear guidance about reading small on-screen text between keyframes.
All names use snake_case with recognizable verb_noun or noun phrasing (reel_transcript, watch_reel, zoom_frames), which reads predictably. The minor inconsistency is that reel_transcript is noun-first while the other two are verb-first, but the intent of each is still obvious.
Three tools form a sensible pipeline (text-only transcript → full visual watch → targeted frame zoom) for a narrowly scoped 'understand a video' server. It sits at the thin end of the appropriate range; a cheap metadata-only or batch-timestamp call would round it out, but nothing is clearly redundant.
The core analysis lifecycle (transcript, visual overview, detailed frame inspection) is covered, but there are notable gaps: YouTube and Threads links are explicitly unsupported despite being common video sources, and there is no lightweight metadata/comments path or audio access. Agents will hit dead ends on non-supported URLs.
Just the caption and timestamped transcript of a video, no images. Use for talking-head videos, podcast clips, or when the user only cares about what is said.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Link to the video. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and openWorld, so safety is covered; the description adds real value by declaring what is returned (caption plus timestamped transcript) and what is deliberately omitted (images). It does not mention edge behavior such as videos with no speech or transcript generation failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, with the defining exclusion ('no images') placed before the usage guidance. Nothing could be removed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so at a high level (caption and timestamped transcript). A few details an agent might want — timestamp format/units, whether the response is paginated for long videos — are absent, but the essentials for selecting and calling the tool are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, 'url', with full schema description coverage, so the baseline is 3. The description adds no constraint on URL type (platform, reel vs. long-form video), so it contributes nothing beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and content scope: 'caption and timestamped transcript of a video, no images.' The 'no images' clause implicitly separates it from the vision-oriented siblings watch_reel and zoom_frames, but those siblings are never named, so differentiation requires the agent to infer it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use for talking-head videos, podcast clips, or when the user only cares about what is said' gives concrete positive selection criteria. It stops short of an explicit inverse rule (e.g. 'use watch_reel when you need visuals'), so the agent must derive the exclusion case itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Watch a short video: an Instagram reel, TikTok, Facebook or X video (YouTube and Threads links get a short "not available yet" note). Also opens Instagram photo posts and carousels.
Returns metadata, caption, a timestamped transcript of the audio, and keyframes picked from scene cuts plus even coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Link to the video. | |
| layout | No | "frames" sends each keyframe as its own image (best detail). "grid" packs them into one labelled contact sheet (cheaper, less detail). | frames |
| from_slide | No | Photo posts only: the slide to start from, for the next page. | |
| max_frames | No | How many keyframes to return (1-20). 8-12 suits most reels. | |
| include_transcript | No | Transcribe the audio. Turn off for music-only clips. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, so the description's job is to add context, which it does by disclosing the return payload shape (metadata, caption, timestamped transcript, keyframes from scene cuts) and the platform-limitation behavior. It stops short of describing failure modes or cost/latency traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs, front-loaded with what it does and what it returns. Every sentence carries information – the platform caveat and the return-value summary both earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly steps in to describe the return payload, and the 100%-covered input schema handles the parameters. It's nearly complete; only error behavior beyond the 'not available yet' note is unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with per-parameter descriptions for layout, from_slide, max_frames, and include_transcript, so the schema carries the semantics. The description adds only indirect hints (keyframes sourced from scene cuts, photo posts/carousels implying from_slide), warranting the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource ('Watch a short video') and enumerates exactly which platforms it covers, plus the non-video Instagram photo/carousel case. It does not differentiate from siblings reel_transcript or zoom_frames, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit inclusion and exclusion guidance ('YouTube and Threads links get a short "not available yet" note'), which tells the agent when this tool will and won't work. It never names the sibling alternatives, though, so the agent gets no routing guidance between watch_reel, reel_transcript, and zoom_frames.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Grab full-resolution frames at specific moments of a reel, e.g. to read small on-screen text or check a detail between keyframes.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Same link passed to watch_reel (it's cached, so this is fast). | |
| timestamps | Yes | Seconds from the start, 1 to 6 of them, e.g. [3.2, 7.5]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered. The description adds real value by specifying that frames are full-resolution and captured at precise moments between keyframes, which is behavioral detail the 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the core action front-loaded and the rationale trailing it. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only tool with a fully described schema, almost everything an agent needs is present. The one residual gap is that no output schema exists and the description doesn't say what comes back per timestamp (image format, one frame per entry), which an agent may wonder about.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both 'url' and 'timestamps' are fully documented, including the 1–6 count and seconds-from-start units. The description's 'at specific moments' adds nothing beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Grab full-resolution frames at specific moments of a reel'. That distinguishes it from reel_transcript and from watch_reel's broader sampling, though the siblings are never named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The clause 'to read small on-screen text or check a detail between keyframes' gives a concrete use case that explains why an agent would reach for this instead of the keyframe-level view. It stops short of stating prerequisites or when not to use it, and leaves the relationship to watch_reel to the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
reel_transcriptwatch_reelzoom_frames
Add one secure layer between your agents and this server.