Prometheor

Cancel a task

cancel

DestructiveIdempotent

Cancels one task of the owner's account: one of yours, or one another AI handed off (own: false in list_tasks), e.g. when the owner asks you to stop it. Idempotent. Later reports from the executor are rejected and the executor is told to stop. For a task of another AI the answer carries its state only (own: false); a reason is kept only for your own tasks. With only_if_waiting true it cancels only a task that has not started yet; use that before you do a queued task's work yourself. A task that already runs stays (cancelled false, started true): then do not do the work too.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "cancel"
  }
}

Input Schema

Name	Required	Description
`number`	No	Instead of task_id: the job's number as the owner says it ("stopp 714", "#714"); cancels every open task of that job.
`reason`	No
`task_id`	No
`reply_session`	No	Only for a Claude Code web session or Claude project chat, and then on every call: your session id or claude.ai/code link (as reply_session in delegate). Only this chat's tasks then count as own; without it you also get other chats' tasks, questions and updates.
`only_if_waiting`	No	Only while the task has not started: withdraw it because you do the work another way. A running task keeps running.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 7, 2026

addedInput schema / properties / number

Added value: +{
+  "description": "Instead of task_id: the job's number as the owner says it (\"stopp 714\", \"#714\"); cancels every open task of that job.",
+  "maxLength": 20,
+  "type": "string"
+}

removedInput schema / required
```
Removed value: -[
-  "task_id"
-]
```

First observedNov 3, 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 annotations (destructive, idempotent, non-readonly) by disclosing consequences: later reports from the executor are rejected, the executor is told to stop, and the returned state flags ('cancelled false, started true') tell the caller whether the cancel actually took effect. It also discloses a data-visibility asymmetry (reason kept only for own tasks, other AIs' tasks return state only) that no annotation conveys.

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?

Purpose and idempotency are front-loaded, and nearly every sentence carries actionable information. Some phrasing is compressed to the edge of readability ('one of yours, or one another AI handed off', 'own: false in list_tasks'), requiring the reader to already know the field convention.

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 destructive, no-output-schema mutation tool this covers what an agent needs: effect on the running executor, idempotency, the running-task edge case and its return flags, and the pre-work cancellation pattern. The only mild gap is that it never states that either task_id or number must be supplied, though the number parameter's schema text implies the substitution.

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 60% and the description compensates for the weak spots: it explains the own:false ownership notion that governs reply_session and reason retention, and spells out only_if_waiting's effect ('cancels only a task that has not started yet') beyond the schema's shorter note. It adds no format or syntax detail for task_id/number beyond what the schema already gives.

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 ('Cancels one task of the owner's account') and bounds the scope to a single task, which distinguishes it from the bulk sibling stop_all. It also clarifies the two ownership cases ('one of yours, or one another AI handed off'), so an agent can identify the right tool without opening the 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 concrete triggers ('when the owner asks you to stop it', 'use that before you do a queued task's work yourself') and a clear when-not behavior ('A task that already runs stays ... then do not do the work too'). It does not explicitly route the agent to stop_all for the cancel-everything case, so it falls just short of naming alternatives.

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

All Prometheor 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?