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. An empty list returns
`{jobs: [], client_note}` — relay `client_note` — not a failed call.

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

Name	Required	Description	Default
`task_tokens`	Yes

Output 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 read-only, idempotent, non-destructive, but the description adds behavior the structured fields cannot: the card self-refreshes while jobs are in flight, an empty result returns {jobs: [], client_note} and is NOT a failure, there is no account-wide history, and output is capped at 20 tokens. These are exactly the runtime traits an agent would otherwise guess wrong.

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 correctly — purpose and when-to-use before mechanics. Dense and mostly earning its length, but the playable-URL-to-open_player guidance appears twice (once in the follow-up paragraph, once in the click/copy paragraph) and the trailing 'next'/'client_note' paragraphs restate instructions already given earlier.

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 needn't be documented, yet the description still explains the meaningful control fields (next, client_note) and how to act on them. Combined with the token sourcing, the 20-item cap, and the empty-list case, an agent has everything needed to call and follow up 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% (task_tokens is a bare array of strings), so the description carries the burden and does: it states the token provenance (task_token returned by transcode_video/start_encode2_raw, or user-pasted), the ordering ('most recent first'), the hard cap of 20, and an explicit anti-pattern ('Do not invent tokens', don't call create_bucket to find jobs).

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 concrete verb+resource+scope: 'Show an inline card of transcoding jobs from this conversation.' It immediately distinguishes itself from the status-query siblings by naming the UI widget form (MCP Apps UI card with filters/expandable rows) versus raw JSON, so an agent can pick it without opening other schemas.

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 triggers ('user asks to see their jobs, a jobs dashboard, the status of several jobs at once, or after you just submitted a job'), an imperative pairing rule (ALWAYS in the same reply as transcode_video/start_encode2_raw), and named alternatives to avoid ('Prefer it over dumping raw get_job_status JSON or looping status yourself'), plus downstream follow-ups keyed to output type.

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.