JANCTION Render

Overview Schema Source Related Servers Discussions Admin

render_cancel

DestructiveIdempotent

Stop a queued or running render job by job_id; queued frames drop, rendered frames are charged, and unused GPU time returns. It cannot be undone or resumed.

Instructions

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

TableJSON 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

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.4.119Oct 15, 2026

addedInput schema / properties / job_id / description

Added 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."

First observedv0.2.1Sep 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the destructiveHint/idempotentHint annotations: it details that queued frames are dropped, already-rendered frames are charged and stay downloadable until expiry, held GPU time is returned, cancellation is irreversible, terminal jobs return unchanged, and assembling jobs cannot be stopped. It also states the auth boundary (only the owning key; otherwise not_found), which annotations do not cover.

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 and scope, then presents effects and edge cases in a logical sequence. It is on the longer side with some mild redundancy around irreversibility, but nearly every clause carries an edge case the agent needs.

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 single-param destructive mutation with an output schema and annotations already present, the description fills every remaining gap: side effects, billing, reversibility, idempotent terminal-state behavior, and permission boundaries.

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 description coverage is 100% for the single job_id parameter, so the baseline is 3, but the description adds the authorization constraint ('Only the key that started the job can stop it; any other job_id returns not_found'), which is behavioral meaning the schema does not carry.

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 and resource ('Stop a queued or running render job of this key') and immediately distinguishes scope by naming the job id formats (j_..., b_...) and the part-job behavior. An agent can tell this apart from render_final/render_status 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operating context: use it to stop a queued/running job, call render_final again to re-render, and 'Ask the user before cancelling a render they asked for.' It does not explicitly contrast against alternatives like render_status or render_final beyond the re-render note, so it stops short of full when/when-not routing.

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

Deploy Server