Skip to main content
Glama

start_encode2_raw

Destructive

Submit a job with the raw query JSON.

The `query` dict can be either the wrapped form `{"query": {...inner...}}`
or the inner object directly — the underlying client auto-wraps if needed.

The inner query MUST have shape:
    {
        "source": "<url>",
        "encoder_version": 2,
        "format": [                 # ARRAY of output specs
            {
                "output": "mp4",    # STRING type field. NOT "format".
                ...                 # encoding params per the recipe
            }
        ]
    }

Common composition mistakes this tool catches up front:
- `"format": "mp4"` inside an entry instead of `"output": "mp4"`.
- Missing `output` field.
- Unknown `output` value.
- `format` as a string at the top level (must be an array).
- `advanced_hls` / `advanced_dash` / `webm_dash` / `hls_audio` without a
  non-empty `stream[]` array (not a drop-in `output` swap on the MP4
  shape — see `qencode://recipe/hls_abr`).
- `vmaf` without `distorted` (`source` = reference, `distorted` = encoded).
- `video_intelligence` without `mode` (use `mode: "description"`, not
  `features`). Source must be https://; `description` modes need ≥10s
  clip, `search` ≥4s — check duration before submit (metadata job).
- `destination.url` as `s3://<bucket>/…` (no regional `*.s3*.qencode.com` host).
  The API treats that as generic S3 and demands `key`/`secret`. Copy
  `{destination_prefix}/{new filename or folder}`. Do not copy a listed
  object's `destination_url` as dest. `stitch[].url`, `distorted`, subtitle
  files, and `logo.source` follow the same public/`cdn_url` vs
  private/`destination_url` rule as `source`. Video Intelligence needs
  `cdn_url` (https only).

Example vmaf query (encoder v1 — set explicitly here):
    {
        "source": "https://example.com/original.mp4",
        "encoder_version": 1,
        "format": [{
            "output": "vmaf",
            "distorted": "https://example.com/encoded.mp4",
            "destination": {"url": "<destination_prefix>/vmaf.json"}
        }]
    }

Example video_intelligence query (encoder v2):
    {
        "source": "https://example.com/input.mp4",
        "encoder_version": 2,
        "format": [{
            "output": "video_intelligence",
            "mode": "description",
            "destination": {"url": "<destination_prefix>/vi"}
        }]
    }

Unlike `transcode_video`, this tool does **not** auto-inject
`encoder_version`. Set `"encoder_version": 2` at the top of the inner
query for all v2 outputs (`smart_thumbnail`, `ai_detection`,
`video_intelligence`, `m4a`, stitch jobs, …). Use `1` only for VMAF per
`qencode://recipe/vmaf_quality`.

Stitching: a stitch job uses a top-level `stitch` array *instead of*
`source` — the two are mutually exclusive, so do NOT also set `source`
(setting both makes the API reject the job). Each `stitch[]` entry is a
URL string or a `{"url": ..., "start_time": ..., "duration": ...}`
object. Media Storage clips: `cdn_url` if public, `destination_url` if
private — same rule as `source`. Example:
    {
        "encoder_version": 2,
        "stitch": [
            {"url": "https://example.com/in.mp4", "start_time": 0, "duration": 5},
            {"url": "https://example.com/in.mp4", "start_time": 148, "duration": 5}
        ],
        "format": [{
            "output": "mp4", "video_codec": "libx264",
            "audio_codec": "libfdk_aac", "bitrate": 2800,
            "framerate": "30", "keyframe": "60", "audio_bitrate": 128
        }]
    }

For complex queries — ABR ladders, DRM, stitching, callbacks — call
`search_qencode_docs(...)` then `fetch_qencode_doc(...)` to read the
matching recipe before composing.

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.

`payload` is an optional opaque callback tag echoed by Qencode, not the
job body (`query` is). It must be a string or omitted. If a JSON object
is passed, this tool returns `{"error": "..."}` asking you to retry
with a string — it does not stringify the object and does not submit.
Do not put `source` / `format` in `payload`.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
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 cover the safety profile (destructive=true, non-idempotent, open-world), and the description adds substantial behavior beyond that: up-front validation of common query mistakes, the auto-wrap behavior of the client, the payload-as-callback-tag semantics and its error-on-object behavior, and the encoder_version divergence from transcode_video. This is a lot of non-obvious operational context.

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?

The lead sentence is front-loaded and every block (validation gotchas, examples, stitching, tool routing) is substantive rather than filler. It is long, and the error-catalog section borders on exhaustive, but the density is largely justified for a tool with a free-form JSON payload and zero schema documentation.

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?

With an output schema present, return values need not be explained, and the description still covers the full job lifecycle around submission. Given the nested free-form query, zero schema coverage, and destructive/non-idempotent annotations, this is about as complete as a definition can be.

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 coverage is 0% and the schema is a bare `additionalProperties: true` object, so the description carries the full burden — and it does: it documents the required inner query shape, the wrapped-vs-unwrapped acceptance, and the `payload` parameter's type constraint, callback-tag purpose, and error behavior. Field-level composition rules for `output`/`format`/`stitch` are also spelled out.

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?

States a specific verb+resource ('Submit a job with the raw `query` JSON') and explicitly contrasts itself with the sibling `transcode_video`, noting it does not auto-inject `encoder_version`. An agent can distinguish it from sibling tools without opening the 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?

Provides explicit when-to-use routing ('For complex queries — ABR ladders, DRM, stitching, callbacks — call `search_qencode_docs(...)` then `fetch_qencode_doc(...)`'), encoder_version selection rules (2 for v2 outputs, 1 only for VMAF), and a prescribed post-submit workflow (list_jobs, open_player, fetch_job_result). It also names usage boundaries such as stitch vs. source mutual exclusivity.

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.