Skip to main content
Glama

transcode_video

Transcode videos with codec support for h264, h265, av1, and vp9, using CRF-based quality control and optional downscaling or fps adjustment.

Instructions

Transcode a video. Quality is CRF-based (lower crf = higher quality).

Codecs: h264 (default, universal), h265, av1 (best compression), vp9. Optionally downscale with scale_height (e.g. 1080) or change fps.

Input Schema

NameRequiredDescriptionDefault
crfNo
fpsNo
inputYes
outputYes
presetNo
overwriteNo
audio_codecNoaac
video_codecNoh264
scale_heightNo
audio_bitrateNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does explain CRF semantics and codec tradeoffs usefully. However, it never mentions that this writes a file, that overwrite defaults to false and can clobber existing output, or anything about long-running encode cost, leaving the destructive/behavioral profile underspecified.

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?

Front-loaded with the core action, then quality semantics, then codec options, with no filler sentences. The bulleted codec list is scannable and every line adds information, though the lack of coverage of half the parameters keeps it from being fully efficient as documentation.

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

Completeness4/5

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

An output schema exists so return values need no explanation, and the description covers the primary knobs (codec, crf, scale, fps) for a re-encode tool. It is still incomplete for a 10-parameter mutating tool, omitting overwrite safety and the audio/preset options that materially affect the result.

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% across 10 parameters, so the description must compensate. It covers crf direction, video_codec options and default, scale_height with an example, and fps, but leaves preset, overwrite, audio_codec, and audio_bitrate entirely undocumented.

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?

Opens with a specific verb+resource ('Transcode a video') and immediately contrasts with siblings by emphasizing re-encoding quality and codec choice, which implicitly separates it from remux_video and transcode_audio. It does not name those siblings, so the differentiation is inferential rather than explicit.

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 codec notes ('h264 default, universal', 'av1 best compression') give some selection guidance, and downscaling/fps are framed as optional. But there is no statement of when to use this instead of remux_video (stream copy) or what prerequisites exist, so the agent must infer the choice.

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