GenFlick

Cancel Work

cancel_work

DestructiveIdempotent

Stop the work, or with task_id one task it delegated, and nothing else. Accepted provider calls may still settle; a stop is not an automatic refund. Tasks the work delegated keep running and stay in get_work, where each can be stopped.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "work_id": "<work_id>",
      "expected_revision": "<expected_revision>",
      "request_key": "<request_key>"
    },
    "name": "cancel_work"
  }
}

Input Schema

Name	Required	Description
`media`	No	What happens to the media this work is generating. cancel stops its generation queue; keep lets it finish and lists it in tasks. Ask the creator which they want. When omitted, media is cancelled.
`task_id`	No	Stop only this task or kept media job from the work's tasks list. Omit to stop the work itself, which never stops its tasks.
`work_id`	Yes	Opaque authorized product identifier; never proof of access.
`request_key`	Yes	Stable caller request key; reuse unchanged after a lost response.
`expected_revision`	Yes	Exact current Work revision returned by Genflick. Stops future descendants where possible; accepted provider work may still settle.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A4.2/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, so the description goes further by disclosing consequences: delegated tasks keep running and accepted provider calls may still settle with no automatic refund. That is substantive context beyond what the annotations convey, though it says nothing about what happens to already-produced media beyond the schema's media enum.

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?

Three short sentences with the scope rule front-loaded, then the settlement caveat, then the delegation caveat. No filler; every clause carries an operational fact.

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 destructive, idempotent mutation with a full output schema and annotations, the description covers the surprising consequences (no refund, orphans survive). It leaves idempotency-key and revision mechanics to the schema, which is reasonable, though a pointer to where stopped work's state can be re-checked would complete it.

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 task_id semantics the description restates are already spelled out in the schema. The media keep/cancel default and expected_revision semantics are covered by the schema alone, so the description adds no parameter detail beyond it.

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 (stop) and resource (work), and pins down the two invocation modes: stop the work itself, or with task_id stop a single delegated task. The 'and nothing else' clause explicitly bounds the blast radius, and it points to get_work as the place lingering tasks remain visible.

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?

Clear guidance on when to pass task_id versus omit it, plus where to find tasks that survived the stop (get_work). It stops short of naming alternatives such as waiting/settling tools or the native stop_work variant, so an agent still has to infer that this only affects the work and not its children.

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

All GenFlick 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.

Resources

Need Help?