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.8/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, and non-destructive behavior, and the description adds substantial behavioral context beyond them: the card refreshes itself while jobs are in flight, clicking a job ID copies the token, there is no account-wide history, and the next/client_note result fields prescribe follow-up actions in the same reply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with front-loaded purpose and clear paragraphs, but it is wordy and repeats itself: the playable-URL-to-open_player instruction appears twice, and the next-field explanation partially restates earlier guidance. A tighter version would preserve all core information with less redundancy.

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 has one parameter, annotations, an output schema, and a rich sibling set, the description is complete. It covers token provenance, caps, refresh behavior, follow-up tool routing, and the no-history constraint, so an agent has everything it needs to invoke the tool correctly and handle results.

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 must carry parameter meaning, and it does: it defines task_tokens as job IDs shown most recent first, capped at 20, and clarifies they come from transcode_video/start_encode2_raw or user-pasted tokens. It even warns against calling create_bucket to find jobs, which is valuable semantics not in the 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 the tool from siblings like get_job_status and refresh_jobs by describing the MCP Apps UI widget, filters, expandable rows, and output URLs, so an agent can pick it correctly.

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/dashboard/status of several jobs, or right after submitting a job with transcode_video/start_encode2_raw. It also names alternatives to avoid, such as dumping get_job_status JSON or looping status checks, and tells the agent to pass task_tokens from the conversation rather than inventing them.

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.