AiLinkAny

Cancel remote task

cancel_task

DestructiveIdempotent

Cancels a previously submitted computer task by command_id. For a queued task this prevents execution. For an active shell_execute task this sends a cancellation control command to the target computer and terminates the real PowerShell process tree. For a completed process_start command whose Process Session is still running, it resolves the retained session_id and reuses process_stop to terminate that process tree. It does not merely relabel cloud state. Use only when the user explicitly wants that task stopped. Calling it again is idempotent.

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": {
      "command_id": "<command_id>"
    },
    "name": "cancel_task"
  }
}

Input Schema

Name	Required	Description	Default
`command_id`	Yes	The command_id of the computer task to cancel.

Output Schema

Name	Required	Description	Default
`ok`	Yes
`method`	Yes
`status`	Yes
`terminal`	Yes
`cancelled`	Yes
`device_id`	Yes
`command_id`	Yes
`device_name`	Yes
`next_action`	Yes
`workflow_id`	Yes
`ai_session_id`	Yes
`cancel_requested`	Yes
`cancel_command_id`	Yes
`process_session_id`	Yes
`process_session_stopped`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The description adds substantial behavioral detail beyond the annotations: queued tasks are prevented from executing, active shell_execute tasks receive a cancellation control command and have their real PowerShell process tree terminated, and completed process_start sessions are resolved and stopped via process_stop. It also clarifies that the tool does not merely relabel cloud state and that repeated calls are idempotent.

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?

The description is front-loaded with the core action and then explains the important behavioral cases. It is somewhat long, but each sentence contributes useful information about cancellation semantics rather than repeating structured fields.

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?

Given the destructive annotation, idempotency annotation, complete parameter schema, and existing output schema, the description provides enough context for an agent to call the tool correctly. It covers the main execution paths and the explicit-user-intent condition without needing to explain return values.

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%, so the command_id parameter is already fully documented in the schema. The description reinforces that cancellation is by command_id but does not add format or validation details beyond what the schema provides.

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 states a specific verb and resource: cancels a previously submitted computer task by command_id. It also distinguishes behavior across queued, active shell_execute, and completed process_start cases, making it clear how this differs from generic process or agent stop tools.

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?

It gives a clear usage condition: use only when the user explicitly wants that task stopped. It does not explicitly name sibling alternatives to use instead, but the case-specific behavior provides strong context for when this tool is appropriate.

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

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