Skip to main content
Glama

start_encode2_raw

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).

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": "s3://.../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": "s3://.../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. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
payloadNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
status_urlNo
task_tokenYes
upload_urlNo

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the sparse annotations, the description explains the client's auto-wrapping behavior, the lack of encoder_version injection, the API rejection when both source and stitch are set, and the upfront validation of common composition mistakes. None of this contradicts the annotations.

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 description is long but tightly organized: core shape first, then common mistakes, examples, stitching, and doc references. It is front-loaded and scannable, though the examples repeat some shape details and the overall length is heavier than strictly necessary.

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?

For a raw-query submission tool, the description covers the query contract, validation failures, v1/v2 versioning, stitch behavior, and recipe lookup. The output schema exists so return-value details are not the description's job; only the minor payload gap keeps this from being perfect, and that is already reflected in parameter semantics.

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?

With 0% schema description coverage, the description carries the burden and does it well for the required query parameter by specifying its shape, examples, and per-output constraints. However, the optional payload parameter is never explained, so one of the two parameters remains semantically undocumented.

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?

The description opens with a specific verb and resource: 'Submit a job with the raw query JSON.' It clearly distinguishes the tool from the sibling transcode_video by stating that it does not auto-inject encoder_version, and it documents the exact raw query shape expected.

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?

It contrasts this tool with transcode_video explicitly, telling users to set encoder_version manually for v2 outputs and use 1 only for VMAF. It also gives route guidance for complex queries ('call search_qencode_docs(...) then fetch_qencode_doc(...)') and warns against mutually exclusive source/stitch combinations.

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.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools are clearly distinct (list_buckets vs list_objects, search vs fetch docs). Minor overlap exists between transcode_video and start_encode2_raw (both submit jobs) and between get_job_status and get_job_status_detailed, but the descriptions explicitly state when to use which, making misselection unlikely.

Naming Consistency4/5

Names overwhelmingly follow verb_noun (create_bucket, list_buckets, get_download_url, transcode_video). A few deviations like start_encode2_raw, wait_for_job, and download_url_to_bucket break the pure pattern, but the convention is still easily predictable.

Tool Count5/5

13 tools is well-scoped for a video encoding platform: bucket management, transcoding submission/status/wait, result retrieval, and docs search/read. Each tool serves a clear purpose without redundancy or bloat.

Completeness4/5

The set covers the main lifecycle: create bucket, ingest via copy, transcode (two entry points), poll status, fetch result, and generate download URLs. Missing cancel/delete operations for jobs and buckets are notable but not critical for core workflows, and the docs tools help fill knowledge gaps.