Skip to main content
Glama

Cancel animation export

cancel_animation_export
DestructiveIdempotent

Cancel an owned export only; retain the source video for another export. Continue polling until a terminal state.

Input Schema

NameRequiredDescriptionDefault
task_idYes

Output Schema

NameRequiredDescriptionDefault
idYesPersist this task ID immediately after create; poll it instead of creating again.
errorNoTask failure details, independently of any usable outputs.
stageNoCurrent pipeline stage when available.
objectYesPublic task resource type.
statusYessucceeded, failed, and cancelled are terminal; cancelling is not terminal.
creditsYesQuoted, reserved, and charged credit states.
outputsNoAvailable assets, including partial outputs on failed/cancelled tasks. Always inspect them at a terminal state.
metadataNoCaller-provided metadata.
progressYesFraction from 0 to 1, not a completion-time estimate.
created_atYesUTC acceptance timestamp.
started_atNoUTC production start when known.
finished_atNoUTC terminal timestamp when known.
resolved_exportNoPersisted FPS sampling summary shared with the quote and manifest; null for legacy tasks.
normalized_inputNoNormalized public input; may contain private prompts or image references. Do not log wholesale.
cancellation_reasonNoStable reason when cancellation is unavailable: TASK_TERMINAL, CANCELLATION_PENDING, CANCELLATION_NOT_CONFIRMED, or GENERATION_ALREADY_SUBMITTED.
cancellation_allowedNoWhether a cancellation request can currently be accepted. Remote cancellation still needs confirmation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / cancellation_allowed
      Added value: +{
      +  "default": false,
      +  "description": "Whether a cancellation request can currently be accepted. Remote cancellation still needs confirmation.",
      +  "title": "Cancellation Allowed",
      +  "type": "boolean",
      +  "x-description-zh": "当前是否允许受理取消请求;远端取消仍须确认。"
      +}
    • addedOutput schema / properties / cancellation_reason
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Stable reason when cancellation is unavailable: TASK_TERMINAL, CANCELLATION_PENDING, CANCELLATION_NOT_CONFIRMED, or GENERATION_ALREADY_SUBMITTED.",
      +  "title": "Cancellation Reason",
      +  "x-description-zh": "不可取消的稳定原因:TASK_TERMINAL、CANCELLATION_PENDING、CANCELLATION_NOT_CONFIRMED 或 GENERATION_ALREADY_SUBMITTED。"
      +}
  2. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true; the description adds genuinely useful context beyond them: cancellation preserves the source video for a later export (bounding the blast radius of the 'destructive' hint) and an ownership constraint. The 'continue polling until a terminal state' instruction also tells the caller what to do next, which is not derivable from the 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?

Two short sentences with the scoping constraint front-loaded and no filler. The polling instruction is slightly abrupt about what to poll (presumably get_animation_export), but the sentence still earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 need not be described, and the description covers ownership, retention of the source asset, and post-cancel polling behavior. The only real omission is identifying what task_id refers to and which tool to poll with.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single task_id parameter has 0% schema description coverage, and the description never mentions it at all. The name and uuid format make its meaning mostly inferable, but the description does not clarify whether it is the export task id or the animation id — a real ambiguity worth documenting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (cancel) and resource (an owned animation export), and the word 'export' naturally separates it from cancel_animation and cancel_video_generation. It does not explicitly name those siblings, so the differentiation is implied by vocabulary rather than spelled out.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

'Cancel an owned export only' implies an ownership precondition and narrows applicability, but there is no explicit when-to-use/when-not framing against cancel_animation or cancel_video_generation. The agent must infer the choice from the resource name alone.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources