Skip to main content
Glama

cancel_task

DestructiveIdempotent

Cancel an unfinished job owned by this connection. Completed work cannot be cancelled.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
task_idYesJob ID returned by start_task.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

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, 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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources