Skip to main content
Glama
goodfy704

AI-video-generator-MCP

by goodfy704

Cancel Video

cancel_video

Cancel an ongoing video-generation job using its unique identifier.

Instructions

Cancel a video-generation job that has not finished yet.

Jobs that are already completed or cancelled cannot be cancelled.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYesIdentifier returned by create_video.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYesIdentifier used to track this job.
promptYesPrompt the job was created from.
statusYesCurrent lifecycle state of the job.
messageYesHuman-readable summary of the job state.
durationYesRequested video length in seconds.
progressYesCompletion percentage, 0-100.
aspect_ratioYesRequested aspect ratio.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses a key behavioral constraint: cancellation is only possible for jobs that have not finished, and completed or already-cancelled jobs cannot be cancelled. It doesn't describe failure modes or whether cancellation is asynchronous, but the most important behavior is covered.

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

Conciseness5/5

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

Two sentences, zero filler. The main purpose is front-loaded, followed by the key limitation. Every part of the description 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?

For a single-parameter tool with an output schema, the description explains the core precondition and edge cases. It could add what happens on attempting to cancel an already completed job, but the provided information is sufficient for an agent to invoke it correctly.

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?

Schema description coverage is 100% and the job_id parameter is described as 'Identifier returned by create_video,' which is precise. The tool description adds no additional parameter meaning, but the baseline of 3 applies because the schema fully documents the parameter.

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 uses a specific verb ('cancel') and resource ('video-generation job'), and immediately clarifies the scope with 'that has not finished yet.' This clearly distinguishes it from sibling tools like create_video, get_video_status, and get_video_result.

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?

The description states when the tool is applicable (only for unfinished jobs) and explicitly excludes jobs that are completed or cancelled. While it doesn't name an alternative tool, the condition is clear enough that an agent knows not to call it for finished jobs.

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