JANCTION Render

Cancel render

render_cancel

DestructiveIdempotent

Stop a queued or running render job of this key (a j_... job, or a b_... job split into parts, which stops every part). Effects: queued frames are dropped; frames already rendered are charged and stay downloadable until the job expires; the rest of the GPU time held for the job is returned to the key at once. It cannot be undone or resumed: to render again, call render_final again (a new job). A job that is already done, failed or canceled is returned unchanged, and a job whose frames are all rendered and is being assembled into the video cannot be stopped (nothing more is charged). Only the key that started the job can stop it; any other job_id returns not_found. Ask the user before cancelling a render they asked for.

Input Schema

Name	Required	Description	Default
`job_id`	Yes	The job_id returned by render_preview or render_final (j_...; a long final split into parts is b_...). Only this key's jobs; in render_status, leave it empty to list them.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 14, 2026

changedInput schema / properties / job_id / description

Previous value: -"The job_id returned by render_preview or render_final (j_...; a long final split into parts is b_...). Only this key's jobs."New value: +"The job_id returned by render_preview or render_final (j_...; a long final split into parts is b_...). Only this key's jobs; in render_status, leave it empty to list them."

Changed1 schema field changedOct 13, 2026

changedInput schema / properties / job_id / description

Previous value: -"The job_id returned by render_preview or render_final (looks like j_...)."New value: +"The job_id returned by render_preview or render_final (j_...; a long final split into parts is b_...). Only this key's jobs."

Changed1 schema field changedOct 7, 2026

addedInput schema / properties / job_id / description

Added value: +"The job_id returned by render_preview or render_final (looks like j_...)."

First observedOct 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare destructive/idempotent/readOnly; the description goes far beyond them by spelling out billing consequences (rendered frames charged, unheld GPU time returned at once), irreversibility (cannot be undone or resumed), which jobs are no-ops, the assembly-stage exception, and the ownership rule (other keys get not_found). This is exactly the behavioral context an agent needs before a destructive call.

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-loads the action, then effects, then constraints, with no filler sentences. It is dense and long for a single-parameter tool, but every clause (billing, irreversibility, ownership, assembly exception) carries distinct information.

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 no explanation, and annotations cover the safety profile. The description still covers the operational gaps that matter: billing impact, irreversibility, edge cases, and authorization scope.

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?

Schema coverage is 100%, so the baseline is 3. The description adds real value on top: it explains the j_... and b_... job_id formats, that a b_ job stop applies to every part, and the not_found behavior for foreign keys, none of which the schema states.

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 ('Stop a queued or running render job of this key') and further distinguishes the two job shapes it handles (j_... and split b_... jobs). An agent can separate this from render_final, render_status, and render_info without opening any 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?

Explicit when-to-use (queued or running job), explicit when-not (already done/failed/canceled, or being assembled into the video), and an explicit alternative path ('to render again, call render_final again'). It also adds a policy instruction to ask the user before cancelling a requested render.

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

All JANCTION Render 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.