qencode

list_jobs

Read-onlyIdempotent

Show an inline card of transcoding jobs from this conversation.

Renders a compact jobs list (MCP Apps UI widget) with status badges,
All/Active/Done/Errors filters, expandable rows, and output URLs. Use this
when the user asks to see their jobs, a jobs dashboard, the status of
several jobs at once, or after you just submitted a job — ALWAYS call this
in the same reply as `transcode_video` / `start_encode2_raw`. Prefer it
over dumping raw `get_job_status` JSON or looping status yourself.
While any listed job is still in flight the card refreshes itself.
If a row is already Done with a playable URL (mp4 / webm / HLS / DASH),
follow with `open_player`. If the deliverable is a json/txt/srt/vtt file,
follow with `fetch_job_result` and give the user the URL plus the
extracted content.

There is NO account-wide job history. Pass `task_tokens` from this
conversation (the `task_token` returned by `transcode_video` /
`start_encode2_raw`, or tokens the user pasted). Do not invent tokens and
do not call `create_bucket` to "find" jobs.

Clicking a job ID (or the copy icon) copies the token. A playable output
URL (mp4 / webm / HLS / DASH) should go to `open_player`.

Args:
    task_tokens: job IDs to show, most recent first. Capped at 20.

When the result carries a non-null `next`, follow it in the same reply
(`open_player` and/or `fetch_job_result`) and tell the user about the
inline player or the extracted file content. `next` is set only when a
listed job is already Done with a matching output.

When the result carries a non-null `client_note`, pass its point on to the
user in the same reply (hosts that collapse the widget until expanded).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`task_tokens`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`jobs`	Yes
`next`	No
`job_count`	Yes
`client_note`	No
`error_count`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 8, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral context beyond that: the card refreshes itself while jobs are in flight, there is no account-wide job history, tokens are capped at 20, and clicking a job ID copies the token. It also explains the meaning of non-null next and client_note fields, which is valuable runtime behavior not visible in 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 well-structured with clear paragraphs and an Args section. It is front-loaded with the core purpose. There is minor redundancy, such as repeating the open_player guidance for playable URLs in two places, but overall each section earns its place by providing actionable routing and constraints.

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?

Given the tool's moderate complexity, the description is complete: it covers when to use, token sourcing, caps, refresh behavior, follow-up actions, and special result fields. The presence of an output schema means the return shape does not need to be spelled out. An agent has everything needed to select and invoke this tool correctly.

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%, so the description carries the full burden for explaining task_tokens. It does so thoroughly: job IDs to show, most recent first, capped at 20, sourced from transcode_video/start_encode2_raw or user-pasted tokens, and explicitly warns not to invent tokens. This adds far more meaning than the bare array-of-strings schema.

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: 'Show an inline card of transcoding jobs from this conversation.' It clearly distinguishes this tool from siblings by stating it is preferred over dumping raw get_job_status JSON or looping status manually. The scope ('from this conversation') and the UI widget nature are unambiguous.

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?

The description gives explicit when-to-use guidance: user asks for jobs, a jobs dashboard, several statuses at once, or immediately after submitting a job. It even mandates calling this tool in the same reply as transcode_video/start_encode2_raw, and provides clear follow-up actions for open_player vs fetch_job_result. It also states what not to do: do not invent tokens and do not call create_bucket to find jobs.

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

All qencode tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.