cancel_task
Cancel an unfinished job owned by this connection. Completed work cannot be cancelled.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Job ID returned by start_task. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Cancel an unfinished job owned by this connection. Completed work cannot be cancelled.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Job ID returned by start_task. |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, and the description does not contradict them. It adds useful context about the scoping (owned by connection) and the limitation (unfinished only). It does not detail side effects beyond cancellation, but the annotation covers the destructive nature, so the description adds sufficient supplementary context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and key constraints. There is no filler or redundant information; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter mutation tool, the description covers the essential constraints (unfinished, owned by connection, completed cannot be cancelled). The output schema (though not shown) is present, so return behavior is likely documented there. This is complete enough for the agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the parameter task_id with a clear description ('Job ID returned by start_task'), so the schema carries the burden. The description does not add any additional parameter semantics, which is acceptable given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'cancel' and the resource 'job/task', and distinguishes it from other operations by specifying 'unfinished job'. It is specific and unambiguous, and differentiates from siblings like start_task and list_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear conditions for use: 'unfinished job' and 'owned by this connection', and explicitly states that completed work cannot be cancelled. It provides practical usage constraints, though it does not mention alternative tools or when not to use it in broader terms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.