Skip to main content
Glama

transcode_video

Destructive

Submit a transcoding job.

Args:
    source: URL of the input video (https://, s3://, or `tus:<uuid>`).
    outputs: list of format-spec dicts. Each MUST have an `output` field
        whose value is one of: mp4, webm, advanced_hls, advanced_dash,
        webm_dash, repack, mp3, m4a, hls_audio, flac, gif, thumbnail,
        thumbnails, smart_thumbnail, metadata, speech_to_text, vmaf,
        video_intelligence, ai_detection, waveform.
        The OUTER array is named `format` in the Qencode schema (this
        tool wraps it for you). The INNER STRING field naming the type
        is `output` — NOT `format`. This is the most common composition
        mistake. Example of a valid entry:
            {
                "output": "mp4",
                "video_codec": "libx264",
                "audio_codec": "libfdk_aac",
                "resolution": 720,
                "optimize_bitrate": 1,
                "audio_bitrate": 128,
                "destination": {
                    "url": "<destination_prefix>/<new filename or folder>"
                }
            }
        Media Storage `destination.url` is `{destination_prefix}/{new key}`
        — a NEW file or folder, never a listed object's `destination_url`
        (that is the existing file, for reading as `source`). Folder
        outputs (HLS / STT / VI / thumbnails) take `{destination_prefix}/folder`
        with no trailing slash. Do not assemble the host.
        `s3://<bucket>/…` is rejected here (the API would demand
        `key`/`secret`). Inputs the encoder fetches (`source`, `distorted`,
        subtitle files, `logo.source`) use `cdn_url` when public and
        `destination_url` when private. Video Intelligence `source` must
        be https — `cdn_url` only; a private object cannot be a VI source.
        For HLS/DASH ABR, put per-rendition params on each entry of an
        inner `stream[]` array (not on the format object directly).
        Output-specific required fields (see matching recipe):
            advanced_hls / advanced_dash / webm_dash / hls_audio —
                non-empty `stream[]` of objects. A bare
                `{"output": "advanced_hls"}` is rejected. Fetch
                `qencode://recipe/hls_abr` (or `audio_outputs` for
                `hls_audio`) before composing.
            vmaf — `distorted` URL of the encoded video; `source` is the
                reference original (encoder v1 is auto-selected).
            video_intelligence — `mode` one of description, categorization,
                moderation, search, custom (NOT `features`). Source must be
                https:// and meet duration minimums (description etc. ≥10s,
                search ≥4s) — check via metadata or tell user if too short.
        Example vmaf entry:
            {
                "output": "vmaf",
                "distorted": "https://example.com/encoded.mp4",
                "destination": {"url": "<destination_prefix>/vmaf.json"}
            }
        Example HLS entry (params on `stream[]`, not on the format object):
            {
                "output": "advanced_hls",
                "segment_duration": 6,
                "stream": [{
                    "video_codec": "libx264",
                    "audio_codec": "libfdk_aac",
                    "resolution": 720,
                    "framerate": "30",
                    "keyframe": "60",
                    "optimize_bitrate": 1,
                    "audio_bitrate": 128
                }]
            }
        Example video_intelligence entry:
            {
                "output": "video_intelligence",
                "mode": "description",
                "destination": {"url": "<destination_prefix>/vi"}
            }
    payload: optional opaque callback tag echoed by Qencode. Must be a
        string (or omitted). A JSON object is not submitted — the tool
        returns `{"error": "..."}` asking you to retry with a string.
        It is not the job body (`outputs` is). Do not put `source` or
        `format` in `payload`.

`encoder_version` is injected automatically when omitted: `2` by default,
`1` when any output is `vmaf`. Stitch jobs (multi-source `stitch` array)
are not supported here — use `start_encode2_raw` with `encoder_version: 2`
per `qencode://recipe/stitching`.

Other composition defaults in this server's instructions (libfdk_aac,
optimize_bitrate, per-stream ABR params, etc.) still belong in each
`outputs[]` entry — consult the matching recipe via
`search_qencode_docs` + `fetch_qencode_doc` before submitting.

After this returns a `task_token`, in the SAME reply call `list_jobs`
with that token. If the job is already Done with a playable video URL,
also `open_player`. If the deliverable is a json/txt/srt/vtt file, call
`fetch_job_result` and give the user both the URL and the extracted
content.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourceYes
outputsYes
payloadNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / payload / anyOf
      Previous value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "additionalProperties": true,
      +    "type": "object"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
  2. Changed4 schema fields changed
    • removedOutput schema / additionalProperties
      Removed value: -false
    • addedOutput schema / oneOf
      Added value: +[
      +  {
      +    "additionalProperties": false,
      +    "properties": {
      +      "status_url": {
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "task_token": {
      +        "type": "string"
      +      },
      +      "upload_url": {
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      }
      +    },
      +    "required": [
      +      "task_token"
      +    ],
      +    "type": "object"
      +  },
      +  {
      +    "additionalProperties": false,
      +    "properties": {
      +      "error": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "error"
      +    ],
      +    "type": "object"
      +  }
      +]
    • removedOutput schema / properties
      Removed value: -{
      -  "status_url": {
      -    "type": [
      -      "string",
      -      "null"
      -    ]
      -  },
      -  "task_token": {
      -    "type": "string"
      -  },
      -  "upload_url": {
      -    "type": [
      -      "string",
      -      "null"
      -    ]
      -  }
      -}
    • removedOutput schema / required
      Removed value: -[
      -  "task_token"
      -]
  3. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare mutation and non-idempotency, and the description adds genuinely non-obvious behavior beyond them: automatic encoder_version injection (2, or 1 when vmaf is present), rejection of s3:// sources because the API would demand credentials, HTTPS-only requirement for video_intelligence sources, per-output validation rejections (bare advanced_hls), and the string-only payload retry contract.

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 one-line purpose, then Args, then workflow. Given 0% schema coverage the bulk is largely justified, but the block is long and the critical post-call workflow guidance is buried at the very end rather than surfaced near the top.

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?

An output schema exists so return values need no explanation, and the description covers everything else an agent needs for a complex multi-format job submission: source rules, per-format composition, validation constraints, defaults, and the required follow-up calls.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden and does so comprehensively: source URL schemes, the outer `format` vs inner `output` naming trap, per-output required fields, destination URL composition rules, and worked examples for vmaf/HLS/video_intelligence. It also clarifies payload is a string-only callback tag and that a JSON object returns an error asking for retry.

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?

Opens with a specific verb+resource ('Submit a transcoding job') that names exactly what happens. It implicitly and explicitly distinguishes itself from siblings by naming start_encode2_raw as the route for stitch jobs, which is not supported here.

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?

Gives explicit routing rules: stitch jobs go to start_encode2_raw, recipes should be fetched via search_qencode_docs/fetch_qencode_doc before composing, and it prescribes the exact post-submission follow-up (list_jobs with the task_token, then open_player or fetch_job_result). Both when-to-use and the alternative are stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.